TM354 Unit 1 - Approaches to Software Development Flashcards

1
Q

What errors can arise in software with the characteristic = Malleability ?

A

As change is easy to make, changes may be be made without thorough consideration

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What errors can arise in software with the characteristic = Complexity ?

A

the more complex the software, the more chance there is of a change affecting other areas

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What errors can arise in software with the characteristic = Size?

A

The greater the number of lines of code, the greater the number of likely errors

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What is the defining quality of good software system?

A

Useful, Usable, Reliable, Flexible, Available, Affordable

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

How does greater flexibility make software system more affordable

A

Users needs change over time. Time to implement change in flexible system is less than for less flexible system. As labour costs are highest component of software cost, flexible s/w is more affordable

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Give 2 reasons why software might not meet users needs

A

software is usually outofdate when delivered because:

  1. some needs are missed during requirements capture
  2. users’ needs change with time
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

suggest a means of measuring maintainability of s/w system

A
  1. effort to locate and fix errors

2. effort to adapt s/w to meet users’ needs

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

what can be learnt from legacy systems about developing good system

A

Legacy sys may start with flexibility, but change over time This needs standards and documentation.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

suggest a reason why legacy systems will always be a problem

A

inherent malleability makes s/w easy to change. Metalworking analogy. Blacksmith - component brittle

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

why consider splitting large project into chunks

A

limit to how much one person can remember at any time. easier to manage tasks if split into chunks

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

how does complexity of s/w affect maintenance

A

it is essential to make change without knowing all about the system. change is difficult when there are many dependencies

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

what is a module

A

module is an identifiable part. that is considered separately

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

why does it help to have low coupling

A

few dependencies. therefore any errors are less likely to propagate through system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

give examples of kinds of info that would be valuable when considering a change

A
2 kinds of info :
which modules are clients of the module in question
what assumptions were made  in client modules of module in questions
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

what are context dependencies

A

services of other modules that module needs to work properly

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

what are benefits of modules with defined interfaces

A

developers need to know only about the module
developers can understand aspects of software more thoroughly
should be easier to find bugs
chance of module reuse increased

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

why does it help to have high cohesion

A
module carries out sensible set of operations or activities.
it implies one major abstraction per module. easier to understand the purpose of module
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

what characteristics should a module display to show it is easy and cheap to develop and maintain

A

module should have low coupling and high cohesion and well defined interface

19
Q

why is it important to achieve balance between coupling and cohesion

A

may have choice between small set of loosely coupled less cohesive modules or larger set of tightly coupled more cohesive modules.former is difficult to understand. In latter, relationships may be over complex

20
Q

suggest similarities and differences between software architecture and building architecture

A

they are both abstractions of the structure of a system. they represent systems that affect concerns of different stakeholders.
Changing a building once complete is expensive. changing details or internal decoration is cheap.
Software different , particularly malleability and complexity

21
Q

what are characteristics of a component

A
component is module with good abstraction for a problem.
component should be capable of being reused or being replaced later within existing software. well defined interface with strong cohesion and low coupling
22
Q

how does concept of an architecture contribute to component reuse

A

arch of s/w sys embodies high level decisions about structure of system and this architec may apply to more than one system

23
Q

which form of decomposition might be used in s/w architecture

A

basic form of decomposition used in s/w arch is partitioning to meet separate concerns, each being addressed by subsystem. e.g separate UI from core business, or build / reuse components for some of the partitions

24
Q

what are similarities and differences between components and services

A

both promote reuse and flexibility.
both use public interfaces to allow requestors to make use of functionality without relying on their implementation
component usually implemented in an oo technology
service uses communication standards that allow interoperation of diverse technologies

25
Q

give characteristics of an engineering approach that support argument that s/w development is an engineering discipline

A
meeting set of requirements
defined process and clear activities
developers can apply skills
validation and verification needed
use of tools and standards
follows code of practice
26
Q

what is a development process

A

set of rules that defines how a sw dev project should be carried out. no of activities and process model indicates how these are ordered

27
Q

difference between customer and user ?

A

customer is person who pays. Users is person who uses.

28
Q

why is maintenance a core activity ?

A

Maint allows a system to evolve over its lifetime so it continues to be useful

29
Q

what task is needed when s/w dev is partitioned into number of increments

A

task devoted to the integration of the increments will be needed

30
Q

what are assumptions of the waterfall model

A

assumption that one activity or phase is finished, it is not revisited.no need for rework. all assumes and endpoint is identified.

31
Q

why might a s/w dev company specialise in specific sector e.g. banking, health

A

through specialisation, company can foster experience in given domain. Developers would have knowledge to understand the problems raised by the users.

32
Q

what is added to a Dev process with introduction of Risk Mgt ?

A

identification, evaluation, reviewing of risks

steps introduce feedback into process - risks are controlled

33
Q

why is traceability important

A

important for reconstruction of significant events

should be able to trace backwards from a component

34
Q

how does doco contribute to traceability

A

doco records the progress from req to implem. u can trace from requirement to implementation

35
Q

what s/w system would you minimize or avoid doco

A

if s/w has short lifespan or will be discarded

36
Q

how would you characterise agile doco?

A

agile doc should be gathered with a purpose.

should be easy to use and justify the effort

37
Q

why is it important to review notebook

A

to identify what worked and what did not. helps to trace events leading to decisions made.

38
Q

What is a model?

A

An abstract representation of a specification, system or point of view

39
Q

What is a good model ?

A

A ‘good model’ is an abstraction that allows those involved to concentrate on the essentials of a complex problem by excluding non-essential details while capturing those of interest.

40
Q

What are 2 kinds of rule that govern the use of a modelling language?

A

A modelling language is normally diagrammatic, although it can be textual. In common with natural language, there are two distinct
kinds of rule:
◦ those that determine whether or not a diagram is legal – the syntax of a diagram
◦ those that define what a legal diagram means – the semantics of a diagram.

41
Q

Does a modelling language need to be associated with a particular development process?

A

No, a modelling language does not dictate how it should be used and it is up to a development process to define which notations are appropriate and how they should be used. With experience practitioners tend to pick and mix from different modelling languages and use the notations that are most appropriate to the task – most modelling languages do not provide notations for all types of tasks.

42
Q

What are the required characteristics of a std modelling language?

A

No, a modelling language does not dictate how it should be used and it is up to a development process to define which notations are appropriate and how they should be used. With experience practitioners tend to pick and mix from different modelling languages and use the notations that are most appropriate to the task – most modelling languages do not provide notations for all types of tasks.

43
Q

How does a standard modelling language contribute to software development?

A
When choosing a modelling language, it should be:
◦ sufficiently expressive
◦ easy to learn and use
◦ unambiguous
◦ widely used
◦ supported by suitable tools.