UNIT 9 – SOFTWARE DEVELOPMENT LIFECYCLES

Learning Outcomes
By the end of this unit students will be able to:

• Describe different software development lifecycles.

LO1

• Explain the importance of a feasibility study.

LO2

• Undertake a software development lifecycle.

LO3

• Discuss the suitability of software behavioural design techniques.

LO4
 LO3 – Undertake a software development lifecycle

Essential Content

 Carry out software development lifecycle:

 Identify requirements: stakeholders; requirements identification;

requirements specification e.g. scope, inputs, outputs, processes and
process descriptors; consideration of alternate solutions and security
considerations; quality assurance required.

 Constraints: specific to activity e.g. costs, organisational policies,

legacy systems, hardware requirements.
 LO3 – Undertake a software development lifecycle

Essential Content

 Report documentation: structure e.g. background information,

problem statements, data collection process and summary,
recommendations, appendices.

 Systems analysis terminology and tools: data stores and entities;

data flows; process representation techniques relationships – 1:1,
1:Many (1:M) and Many:Many (M:M).

 Investigation: e.g. upgrading computer systems, designing new

systems.
 LO3 – Undertake a software development lifecycle

Essential Content

 Techniques: examples relevant to methodology chosen e.g. Context

Diagrams, Data Flow Diagrams (DFDs), Entity Relationship
Diagrams (ERDs); Business Systems Options (BSOs); Technical
Systems Options (TSOs); quality considerations e.g. Total Quality
Management (TQM).
Identify requirements

 Stakeholders
 Each of these groups of people has its own requirements,
interests, and needs to be met by the software system.

 We refer collectively to these people as stakeholders.

 Understanding the role of the stakeholder is fundamental to

understanding the role of the architect in the development of a
software product or system.
Identify requirements

 Requirements identification
 This phase is critical to the success of the project.  
 Expectations (whether of a client or your team) need to be
fleshed out in great detail and documented. 
 This is an iterative process with much communication taking
place between stakeholders, end users and the project team.
Identify requirements

 Requirements specification
 Scope
 provides a framework for the project and guides the requirements
collection process.
 is usually the first source of information about the project
available to all stakeholders before the project gets under way.

 Inputs
 It is important to design appropriate data input methods to
prevent errors while entering data.
Identify requirements

 Requirements specification
 Outputs
 The design of output is the most important task of any
system.
 During output design, developers identify the type of
outputs needed, and consider the necessary output
controls and prototype report layouts.
 Identify requirements

 Requirements specification
 Processes and process descriptors
 Process framing defines the process boundaries, the major activities, the
actors, key metrics, the case for action, and the vision for the future process.
 The process framing can then be used to draft key business requirements
for the new system.

 Process descriptor - A set of information that defines the status of resources
allocated to a process.
 When a system contains a number of processes, any of which may be
active at any one time, there will be for each process a descriptor defining
the status of that process. 
Identify requirements

 Consideration of alternate solutions and security considerations:

 It is important that multiple alternatives be considered.
Potential solutions (decision alternatives) should be
adequately described to make them understandable to
everyone involved in the development.

 All of these business processes and information require

some level of security processing. One type of security
is required to protect the client, another to protect the
corporation.
 Identify requirements

 Quality assurance:
 Software quality assurance is the process of evaluating how
well software meets the needs of the end customer.

 QA revolves around three pillars: reliability, efficiency, and

flexibility. In order for software to be useful, it needs to work
consistently, complete tasks quickly, and be useful in a variety
of situations.

 Furthermore, good software also needs internal quality controls,

making sure the underlying code is clean and practical.
Constraints

 Constraints: specific to activity e.g.

 Costs

 the process of isolating and estimating costs and benefits

 system costs

 benefits from the system

 Organisational policies

 Whether the proposed system is consistent with the organization’s

strategic objectives?
 Report documentation

 Background information

 About the client business/organization and current IT system

 Problem statements

 Problem definition: On receiving a request from the user for systems development,
an investigation is conducted to state the problem to be solved.
 Data collection process and summary

 process of gathering and measuring information

 Quantitative Data. These are data that deal with quantities, values or numbers,
making them measurable.
 Qualitative Data. These data, on the other hand, deals with quality, so that they
are descriptive rather than numerical in nature
Report documentation

 Recommendations
 E.g. features to be implemented in the new system

 Appendices
 An appendix contains supplementary material that is not an essential
part of the text itself but which may be helpful in providing a more
comprehensive understanding of the project
Report documentation

 Recommendations
 E.g. features to be implemented in the new system

 Appendices
 An appendix contains supplementary material that is not an
essential part of the text itself but which may be helpful in
providing a more comprehensive understanding of the project
Systems analysis terminology and tools

 Data stores and entities

 A data store is a place where data is stored and retrieved within the
system.

 Data flows
 Data-flows are used to model the flow of information into the system,
out of the system, and between elements within the system.
Systems analysis terminology and tools

 Process representation techniques relationships – 1:1, 1:Many (1:M)

and Many:Many (M:M).

 One-to-one (1:1)

 This is where one occurrence of an entity relates to only one

occurrence in another entity.

 For example, an employee is allocated a company car, which

can only be driven by that employee.

 Therefore, there is a one-to-one relationship between employee

and company car.
Systems analysis terminology and tools

 One-to-Many (1:M)

 Is where one occurrence in an entity relates to many occurrences

in another entity.

 For example, taking the employee and department entities

shown on the previous page, an employee works in one
department but a department has many employees.

 Therefore, there is a one-to-many relationship between

department and employee.
Systems analysis terminology and tools

 Many-to-Many (M:N)

 This is where many occurrences in an entity relate to

many occurrences in another entity.

 For example, an employee may work on several projects

at the same time and a project has a team of many
employees.

 Therefore, there is a many-to-many relationship between

employee and project.
Systems analysis terminology and tools

 Relationship cardinality
Investigation

 E.g. upgrading computer systems vs. designing new systems.

 To choose the option that is best, first weigh the costs, benefits and risks
associated with each type of change.

 So what are some reasons to implement new systems?

 Many legacy system are coded in languages that are no longer widely
in use, meaning that there aren’t many personnel qualified to work with
them.

 And in some cases, the companies that created the software in the
first place no longer support it.
Investigation

 If you choose to completely overhaul your current legacy system, you can
use new technology to improve user experience and decrease costs over
time. But as mentioned above, implementing a new system all at once
can be costly. 

 In some cases, new systems can mean new bugs as well.

 When companies choose to update their current systems rather than

begin a full-scale overhaul, they gain access to potential benefits more
quickly.
 making changes to old systems is to add on to
what currently exists.
Techniques - DFD

 Context Diagrams, Data Flow Diagrams (DFDs)

 A data flow diagram (DFD) illustrates how data is

processed by a system in terms of inputs and outputs.

  A context diagram is a top level (also known as

"Level 0") data flow diagram.
 It only contains one process node ("Process 0") that
generalizes the function of the entire system in
relationship to external entities.
Techniques - DFD

 Two common systems of DFD symbols are named after their

creators:
Techniques - DFD

 Rules:
 Naming conventions:
 Processes: strong verbs
 Data flows: nouns
 Data stores: nouns
 Entities: nouns

 No more than 7 - 9 processes in each DFD.

 Data flows must begin, end, or both begin & end with a
process.
Techniques - DFD

 Rules:
 Leveling Conventions:

 Numbering: The system under study in the context

diagram is given number `0'.
 The processes in the top level DFD are labeled
consecutively by natural numbers beginning with 1.
 When a process is exploded in a lower level DFD, the
processes in such lower level DFD are consecutively
numbered following the label of such parent process
ending with a period or full-stop (for example 1.2, 1.2.3,
etc.).
Techniques - DFD

 Rules:

 Balancing:

The set of DFDs pertaining to a system

must be balanced in the sense that
corresponding to each dataflow beginning
or ending at a process there should be an
identical dataflow in the exploded DFD.
DFD

 Context Diagrams, Data Flow Diagrams (DFDs)

 DFDs exist in a hierarchy, beginning with the simplest, highest,
system level and ending with the lower level diagrams with detailed
processes.

 The DFD at the system level illustrates the context, that is, the
circumstances of its environment and is called the context
diagram.

 This diagram contains only a single, unnumbered process bubble

in the shape of a circle to represent the entire system.
DFD – Context Diagram

 The context diagram Latinitas “system” with a single

process bubble in the middle. Its five entities are
represented by squares. The system is connected to its
entities by arrows that represent data flows.
DFD – Level 1
DFD – Level 2
ERD

 Entity Relationship Diagrams (ERDs)

 An ERD is a means of visualizing how the information a
system produces is related. There are five main components of
an ERD:

 Entities, which are represented by rectangles. An entity is an

object or concept about which you want to store information.
ERD

 Actions/Relationship, which are represented by diamond shapes, show

how two entities share information in the database.

 In some cases, entities can be self-linked. For example, employees can

supervise other employees.
ERD

 Attributes, which are represented by ovals. A key attribute is the

unique, distinguishing characteristic of the entity. For example, an
employee's social security number might be the employee's key
attribute. 
ERD

 Connecting lines, solid lines that connect attributes to show the

relationships of entities in the diagram.

 Cardinality specifies how many instances of an entity relate to one instance

of another entity.

 Ordinality is also closely linked to cardinality. While cardinality specifies the

occurrences of a relationship, ordinality describes the relationship as either
mandatory or optional.

 In other words, cardinality specifies the maximum number of relationships

and ordinality specifies the absolute minimum number of relationships.
ERD

Employ

Handle
BSO

 Business Systems Options (BSOs)

 A BSO defines the functional scope of a proposed
solution.
 At its most basic level it consists of textual descriptions
of those requirements satisfied by the solution.
 All BSOs must satisfy the minimum requirement as
identified by user representatives.
 Business Systems Options are developed during
Feasibility Study and Requirements Analysis.
TSO

 Technical Systems Options (TSOs)

A TSO defines a possible technical

environment for the implementation of
the system.
 It will include descriptions of hardware
and software, technical support
arrangements, distribution of the
system and development tools
TQM

 Quality considerations e.g. Total Quality Management (TQM).

 TQM is a management approach aimed at satisfying all the
customer requirements, needs and expectations using a
continuous improvement approach

 There are three aspects of software quality:

 functional quality,
 structural quality
 process quality
TQM

 However, the quality of software is estimated by many of its

attributes such as reliability, integrity, maintainability, enhance
ability (extensibility), usability, portability, and reusability

 The functionality of the software and the appearance of the user

interface could also affect software quality.

 Consequently, these characteristics can affect user satisfaction

so it could be used as a measure of software quality.
TQM

 Functional quality means that the software performs the tasks

it is intended to do for its users correctly. Software testing
commonly focuses on functional quality.

 The second aspect of software quality, structural quality,

means the code itself is well structured. Unlike functional
quality, structural quality is hard to test for.

 The third aspect, process quality, it is the quality of the

development process significantly affects the value received by
users, development teams, and sponsors, and all three groups
have a stake in improving software quality.
References

 https://www.viewpoints-and-perspectives.info/home/stak
eholders/
 https://airbrake.io/blog/sdlc/what-is-the-software-develo
pment-life-cycle
 https://www.mitre.org/publications/systems-engineering-
guide/se-lifecycle-building-blocks/requirements-enginee
ring/eliciting-collecting-and-developing-requirements
 https://www.tutorialspoint.com/system_analysis_and_de
sign/system_analysis_and_design_input_output_forms.h
tm
 https://www.computereconomics.com/article.cfm?id=21
57
 https://www.encyclopedia.com/computing/dictionaries-t