INF3705 Assignment 2

Student No: 32063253

Question 1

Highest priority is to satisfy customer through early and continuous delivery of valuable software
Welcome changing requirements even late in development, accommodating change is viewed as
increasing the customer's competitive advantage
Delivering working software frequently with a preference for shorter delivery schedules (e.g.,
every 2 or 3 weeks)
Business people and developers must work together daily during the project
Build projects around motivated individuals, given them the environment and support they
need, trust them to get the job done
Face-to-face communication is the most effective method of conveying information within the
development team
Working software is the primary measure of progress
Agile processes support sustainable development, developers and customers should be able to
continue development indefinitely
Continuous attention to technical excellence and good design enhances agility
Simplicity (defined as maximizing the work not done) is essential
The best architectures, requirements, and design emerge from self-organizing teams
At regular intervals teams reflects how to become more effective and adjusts its behaviour
accordingly

Question 2
Specification
The functionality of the software and constraints on its operation must be defined.
The software requirements document (sometimes called the software requirements specification or
SRS) is an official statement of what the system developers should implement. It should include both
the user requirements for a system and a detailed specification of the system requirements.
Validation
The software must be validated to ensure that it does what the customer wants.
Requirements validation is the process of checking that requirements actually define the system that
the customer really wants. It overlaps with analysis as it is concerned with finding problems with the
requirements. Requirements validation is important because errors in a requirements document can
lead to extensive rework costs when these problems are discovered during development or after the
system is in service.
Evolution
The software must evolve to meet changing customer needs.
The flexibility of software systems is one of the main reasons why more and more software is being
incorporated in large, complex systems. Once a decision has been made to manufacture hardware, it
is very expensive to make changes to the hardware design. However, changes can be made to

software at any time during or after the system development. Even extensive changes are still much
cheaper than corresponding changes to system hardware.
Question 3
Requirements specification is the process of writing down the user and system requirements in a
requirements document. Ideally, the user and system requirements should be clear, unambiguous,
easy to understand, complete, and consistent.
In practice, this is difficult to achieve as stakeholders interpret the requirements in different ways
and there are often inherent conflicts and inconsistencies in the requirements.
The user requirements for a system should describe the functional and non-functional requirements
so that they are understandable by system users who dont have detailed technical knowledge.
Ideally, they should specify only the external behaviour of the system. The requirements document
should not include details of the system architecture or design.
Consequently, if you are writing user requirements, you should not use software jargon, structured
notations, or formal notations.
You should write user requirements in natural language, with simple tables, forms, and intuitive
diagrams.
System requirements are expanded versions of the user requirements that are used by software
engineers as the starting point for the system design. They add detail and explain how the user
requirements should be provided by the system. They may be used as part of the contract for the
implementation of the system and should therefore be a complete and detailed specification of the
whole system.
Ideally, the system requirements should simply describe the external behaviour of the system and its
operational constraints. They should not be concerned with how the system should be designed or
implemented.
Question 4
As a software designer, you can use models of application architectures in a number
of ways:
As a starting point for the architectural design process If you are unfamiliar with the type of
application that you are developing, you can base your initial design on a generic application
architecture. Of course, this will have to be specialized for the specific system being developed,
but it is a good starting point for design.
As a design checklist If you have developed an architectural design for an application
system, you can compare this with the generic application architecture. You can check that your
design is consistent with the generic architecture.
As a way of organizing the work of the development team The application architectures
identify stable structural features of the system architectures and in many cases, it is possible to
develop these in parallel. You can assign work to group members to implement different
components within the architecture.
As a means of assessing components for reuse If you have components you might be able to
reuse, you can compare these with the generic structures to see whether there are comparable
components in the application architecture.

As a vocabulary for talking about types of applications If you are discussing a specific application
or trying to compare applications of the same types, then you can use the concepts identified in
the generic architecture to talk about the applications.

Question 5
Unit Testing, where individual program units or object classes are tested. Unit testing should focus
on testing the functionality of objects or methods.
Component Testing, where several individual units are integrated to create composite components.
Component testing should focus on testing component interfaces.
System Testing, where some or all of the components in a system are integrated and the system is
tested as a whole. System testing should focus on testing component interactions.
Question 6
Fault repairs Coding errors are usually relatively cheap to correct; design errors are more expensive
as they may involve rewriting several program components. Requirements errors are the most
expensive to repair because of the extensive system redesign which may be necessary.
Environmental adaptation This type of maintenance is required when some aspect of the systems
environment such as the hardware, the platform operating system, or other support software
changes. The application system must be modified to adapt it to cope with these environmental
changes.
Functionality addition This type of maintenance is necessary when the system requirements change
in response to organizational or business change. The scale of the changes required to the software is
often much greater than for the other types of maintenance.
In practice, there is not a clear-cut distinction between these types of maintenance. When you adapt
the system to a new environment, you may add functionality to take advantage of new
environmental features. Software faults are often exposed because users use the system in
unanticipated ways. Changing the system to accommodate their way of working is the best way to
fix these faults.
Question 7
With legacy system evolution, the system should first be assessed to determine what option to
select. Depending on what cluster your legacy system is classified in after the assessment (low
quality & business value, low quality & high business value, high quality & low business value, or high
quality & business value), one should approach the following strategic options for legacy system
evolution:

Completely get rid of the system.

Continue with regular maintenance of the system without changes.
Reengineer the system to approve its maintainability.
Replace all or part of the system with a new system.

Question 8

The organization is small and operates with a homogeneous network and technology confined to
a single vendor.

The organization does not require standards based integration. Product vendors are promoting a
complex SOA stack as a solution for large enterprises where integration is a requirement. Some
enterprises may not need choreography, BPEL engine and Orchestration. Instead, the solution
might be a simple data exchange between applications and external systems.

The organization cannot afford the cost of implementation. Many SOA stack based solutions
require their own application servers, BPEL engines, and Process Serversa major cost to the
enterprise.

The organization requires systems where response times are critical. SOAs are not suitable in
such environments. Tight coupling architecture is the better solution for improving response
times.

The organization does not need to change the existing legacy system. In such a situation, SOA is
overkill. These Legacy systems and the applications running on them perform better as long as
they are not messed up.

If the business logic, presentation, data flow, process, or any other aspect of the application do
not require significant change, converting these giants to an SOA might not return sufficient
value.

Architecting loosely coupled services of an application to be deployed on a single computer is

not cost effective; SOA is not suitable in such circumstances.