ICT 2133

Software Engineering
Answers for tutorial No 02
1. A structured set of activities required to develop a software system is
known as software process.
2. Waterfall model
Incremental Development model
Spiral model
V model
RAD model
3. The waterfall model describes a development method that is linear and

sequential. Waterfall development has distinct goals for each phase of

development.Once a phase of development is completed, the
development proceeds to the next phase and there is no turning back.

Drawbacks:
The difficulty of accommodating change after the process is
underway. In principle, a phase has to be complete before
moving onto the next phase.
Inflexible partitioning of the project into distinct stages makes it
difficult to respond to changing customer requirements.
4. Incremental development is based on the idea of developing an initial
implementation,exposing this to user comment and evolving it through
several versions until anadequate system has been developed.

Specification, development, andvalidation activities are interleaved

rather than separate, with rapid feedback across activities.

Benefits:
The cost of accommodating changing customer requirements is
reduced.
It is easier to get customer feedback on the development work
that has been done.
More rapid delivery and deployment of useful software to the
customer is possible.
Problems:
The process is not visible.
Managers need regular deliverables to measure progress. If systems
are developed quickly, it is not cost-effective to produce documents
that reflect every version of the system.
System structure tends to degrade as new increments are
added.
Unless time and money is spent on refactoring to improve the
software, regular change tends to corrupt its structure. Incorporating
further software changes becomes increasingly difficult and costly.

5. Dissatisfaction with the overheads involved in software design

methods of the 1980s and 1990s led to the creation of agile methods.
These allowed the development team to focus on the software itself
rather than on its designand documentation. Agile methods universally
rely on an incremental approach to software specification,
development, and delivery. They are best suited to application

development where the system requirements usually change rapidly

during the development process. They are intended to deliver working
software quickly to customers, who can then propose new and changed
requirements to be included in later iterations of the system.
6. Extreme Programming
Scrum
Crystal clear
7. Customer involvement
Incremental delivery
People not process
Embrace change
Maintain simplicity
8. Scrum is an agile method that focuses on managing iterative
development rather than specific agile practices.
There are three phases in Scrum.
a. The initial phase is an outline planning phase where you
establish the general objectives for the project and design the
software architecture.
b. This is followed by a series of sprint cycles, where each cycle
develops an increment of the system.
c. The project closure phase wraps up the project, completes
required documentation such as system help frames and user
manuals and assesses the lessons learned from the project.
9. Extreme programming (XP) is perhaps the best known and most widely
used of the agile methods. In extreme programming, requirements are
expressed as scenarios (called user stories), which are implemented
directly as a series of tasks. Programmers work in pairs and develop
tests for each task before writing the code. All tests must be
successfully executed when new code is integrated into the system.
10.
Pair programming involves programmers working in pairs,
developing code together. Pairs are created dynamically so that all
team members work with each other during the development process.
This helps develop common ownership of code and spreads knowledge
across the team. It serves as an informal review process as each line of
code is looked at by more than 1 person.It encourages refactoring as
the whole team can benefit from improving the system code.
11.
Programming team look for possible software improvements and
make these improvements even where there is no immediate need for

them is known as refactoring.This improves the understandability of

the software and so reduces the need for documentation.
12.
Increased time in rework
Slow feedback
Hard to refactor the code
13.
The Scrum master is a facilitator who arranges daily meetings,
tracks the backlog of work to be done, records decisions, measures
progress against the backlog and communicates with customers and
management outside of the team.The whole team attends short daily
meetings (Scrums) where all team members share information,
describe their progress since the last meeting, problems that have
arisen and what is planned for the following day. This means that
everyone on the team knows what is going on and, if problems arise,
can re-plan short-term work to cope with them.
14.

Reasons:The informality of agile development is incompatible with the

legal approach to contract definition that is commonly used in
large companies.
Agile methods are most appropriate for new software
development rather than software maintenance. Yet the majority
of software costs in large companies come from maintaining their
existing software systems.
Most software contracts for custom systems are based around a
specification, which sets out what has to be implemented by the
system developer for the system customer.
Agile methods are designed for small co-located teams yet much
software development now involves worldwide distributed teams.

15.
The requirements are the descriptions of the system services and
constraints that are generated during the requirements engineering
process.
16.
User requirements
Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for customers.
System requirements
A structured document setting out detailed descriptions of the
systems functions, services and operational constraints. Defines what
should be implemented so may be part of a contract between client
and contractor.

17.
The process of establishing the services that a customer requires
from a system and the constraints under which it operates and is
developed is known as requirement Engineering.
18.
Requirement elicitation means finding out about the application
domain, the services that the system should provide and the systems
operational constraints by working with customers.
19.

Stakeholders dont know what they really want.

Stakeholders express requirements in their own terms.
Different stakeholders may have conflicting requirements.
Organisational and political factors may influence the system
requirements.
The requirements change during the analysis process. New
stakeholders may emerge and the business environment may
change.

20.
Ethnography is an observational technique that can be used to
understand operational processes and help derive support
requirements for these processes. An analyst immerses himself or
herself in the working environment where the system will be used. The
day-to-day work is observed and notes made of the actual tasks in
which participants are involved.
21.
a.
b.
c.
d.
e.

Natural language
Structured natural language
Design description languages
Graphical notations
Mathematical specifications

22.
23.
a. Requirements reviews:- The requirements are analyzed
systematically by a team of reviewers who check for errors and
inconsistencies.
b. Prototyping:- In this approach to validation, an executable model
of the system in question is demonstrated to end-users and
customers. They can experiment with this model to see if it
meets their real needs.

c. Test-case generation:- Requirements should be testable. If the

tests for the requirements are devised as part of the validation
process, this often reveals requirements problems. If a test is
difficult or impossible to design, this usually means that the
requirements will be difficult to implement and should be
reconsidered.Developing tests from the user requirements before
any code is written is an integral part of extreme programming.
24.
Use cases are a requirements discovery technique. A use case
identifies the actors involved in an interaction and names the type of
interaction. The set of use cases represents all of the possible
interactions that will be described in the system requirements. Use
cases are effective techniques for eliciting requirements from
stakeholders who interact directly with the system. Each type of
interaction can be represented as a use case.
25.

26.
Testing is intended to show that a program does what it is
intended to do and to discover program defects before it is put into
use. Testing cannot demonstrate that the software is free of defects or
that it will behave as specified in every circumstance. It is always

possible that a test that you overlooked could discover further

problems with the system. So, Testing can only show the presence of
errors, not their absence.

27.
a.
Black Box Testing
Black-box testing treats software
under test as a black-box without
knowing its internals. Tester is aware
of what the program should do but
does not have the knowledge of how
it does it. It provides external
perspective of the software under
test.

White Box Testing

White-box testing looks inside the
software that is being tested and
uses that knowledge as part of the
testing process. White-box testing
requires internal knowledge of the
system and programming skills. It
provides internal
perspective of
the software under test.

b.
Verification

Validation

"Are we building the product right.

"Are we building the right product.

The aim of verification is to check

that the software meets its stated
functional
and
non-functional
requirements

Validation, however, is a more general

process. The aim of validation is to
ensure that the software meets the
customers expectations.

c.
Defect Testing

Validation Testing

Discover situations in which

the behavior of the software is
incorrect, undesirable, or does
not
conform
to
its
specification.
The test cases are designed to
expose
Defects and that can be
deliberately obscure and need
not reflect how the system is
normally used.

Demonstrate to the developer

and the customer that the
software meets its
requirements.
Expect the system to perform
correctly using a given set of
test cases that reflect the
systems expected use.

d.
Unit Testing

Component Testing

Individual program units or object Several individual units are integrated

classes are tested.
to create composite components.
Unit testing should focus on testing Component testing should focus on
the functionality of objects or testing component interfaces.
methods.