Running Head: OOP

Application Engineering
[Name of the Writer]
[Name of Institution]
[Dated]

Table of Contents
Part I.................................................................................................................................................4
Traditional SDLC: Waterfall Model.........................................................................................4
Phases of Waterfall Model................................................................................................5
Rapid Application Development Model....................................................................................7
Phases of RAD..................................................................................................................7
Difference between RAD Model and Waterfall Model.............................................................9
Similarities between RAD Model and Waterfall Model............................................................9
Traditional Structure Methodologies versus Traditional Object Oriented Methodologies....10
Object Modelling Technique...................................................................................................10
Stages of Object Modelling Technique............................................................................11
Structured Systems Analysis and Design Method...................................................................12
Stages of SSADM............................................................................................................13
Similarities between OMT and SSADM.................................................................................15

OOP 2
Differences between OMT and SSADM..................................................................................15
Agile Software Development Methods...................................................................................16
Scrum..............................................................................................................................16
Extreme Programming....................................................................................................18
Test Driven Development................................................................................................19
Part II.............................................................................................................................................21
Case Study..............................................................................................................................21
Functional Requirement.........................................................................................................21
Use Case Diagram for St Patricks Staff Management System..............................................23
Class Diagram for St Patricks Staff Management System....................................................24
Sequence Diagram for the St Patricks staff management system..........................................25
Robustness Diagram...............................................................................................................26
Software Development Methodology......................................................................................26
ICONIX Features............................................................................................................27
Fundamentals of processes.............................................................................................28
Tools................................................................................................................................28
Preliminary Review / Analysis Design and Preliminary Design.....................................29
Critical Design Review / Design.....................................................................................30
Implementation................................................................................................................30
Implementation of ICONIX Methodology to St-Patricks online system................................31
ST-PATRICKS ONLINE DOMAIN MODEL.........................................................................33
Testing.....................................................................................................................................33
References......................................................................................................................................36

OOP 3
Application Engineering
Part I
Traditional SDLC: Waterfall Model
Waterfall model is the methodological approach that orders rigorously stages of the
process for software development, so that the start of each stage must wait for the completion of
the previous stage.
An example of a cascade development methodology is:
1.
Requirements analysis.
2.
System Design.
3.
Program Design.
4.
Coding.
5.
Tests.
6.
Implementation.
7.
Maintenance.
Thus, any design error detected in the testing phase necessarily lead to redesign and
reprogramming the affected code, increasing development costs. The word suggests cascade
through the metaphor of gravity, the effort needed to make a change in the later stages of a
project (Laplante, & Neill, 2004). While it has been widely criticized from academia and
industry, yet it still remains the paradigm more often today.

Figure 1: Waterfall Model

OOP 4
Phases of Waterfall Model
Requirements Analysis: At this stage the needs of the end users of software are analysed
to determine what objectives should cover. In this phase, a memory called SRD (requirements
specification document) containing the complete specification of what the system should do
without entering internal details emerged.
It is important to note that at this stage should agree on everything that is required of the
system and that what will be in the following stages, no new results may be needed half of the
software development process.
System Design: This phase decomposes and organizes the system elements that can be
developed separately, taking advantage of the development team. As a result the SDD (Software
Design Document), which contains the description of the global relational structure of the system
and specifying what to do each of its parts, arises, and how they combine with each other.
It is useful to distinguish between high-level design and architectural and detailed design.
The first is to define the structure of the solution (once the analysis phase described the problem)
identifying large modules (sets of functions that will be associated) and their relationships. This
architecture defines the chosen solution. The second defines the algorithms and code
organization to begin implementation.
Program Design: This is the stage where the algorithms necessary for the fulfilment of
user requirements as well as analysis necessary to know that tools used in the encoding step is
performed.
Coding: This is the stage where the implemented source code, using prototypes and
testing and trials to correct errors. Depending on the programming language and version libraries
and reusable components within the same project are created to make programming is a much
faster process (Gilb, 1985).
Testing: The elements, as scheduled, are assembled to compose the system and verify
that it works properly and meets the requirements before being delivered to the end user.

OOP 5
Verification: This is the stage where the end user runs the system, for which the
programmers or already performed extensive testing to verify that the system does not fail.
Maintenance: One of the most critical stages, as it allocates 75% of resources, is the
maintenance of the Software and that when used as an end user might not meet all our
expectations.

Rapid Application Development Model

The rapid application development or RAD is a software development process, originally
developed by James Martin en1980. The method comprises the interactive development,
prototyping and use of CASE (Computer Aided Software Engineering). Traditionally, the rapid
development of applications tends to also include usability, usefulness and speed of execution
(Beynon-Davies et.al, 1999).
Today is often used to refer to the rapid development of graphical user interfaces such as
Glade or complete integrated development environments. Some of the most popular platforms
are Visual Studio, Lazarus, prawns, Delphi, Foxpro, Anjuta, Game Maker, Velneo or Clarion. In
the area of multimedia authoring software as Neosoft Neoboo and Multimedia Builder
MediaChance platforms provide rapid application development, within certain limits.
Phases of RAD
Requirements planning phase: This phase combines elements of system planning and
systems analysis phases of system development. Users, administrators and IT staff discuss and
agree on business needs, the project scope, constraints and system requirements. Ends when the
team agrees on the key issues and obtains authorization from the administration to continue.

OOP 6
User Design Phase: During this phase, users interact with systems analysts and
development of models and prototypes that represent all system processes, inputs and outputs.
The RAD groups or subgroups typically use a combination of techniques common application
development and CASE tools to translate user requirements into working models. User Design is
an ongoing interactive process that allows users to view, modify, and eventually approve a
working model of the system that fits your needs.
Construction phase: This phase focuses on programs and development tasks similar to
SDLC applications. In RAD, however, users can still continue to participate and suggest changes
or improvements actual screens or reports are developed. Its functions include programming and
application development, coding, unit testing and system integration (Mackay et.al, 2000).
Cutover phase: This phase resembles the final tasks in the implementation phase of
SDLC, including data conversion, testing, change to the new system and user training. Compared
with traditional methods, the process is compressed. As a result, the new system is built,
delivered and placed into operation much sooner.

OOP 7
Figure 2: RAD Model

Difference between RAD Model and Waterfall Model

RAD
It is a linear software process
During the planning, analysis, and the testing

Waterfall
It is a sequential software development process
During the planning, analysis, and the testing

heavy involvement of the customers are

phase heavy involvement of the clients are

required
Not Favourable under situations where batch

required
Beneficial under situations where batch

processes are required

It is all about building relevant systems

processes are required

It is all about building reliable systems

Similarities between RAD Model and Waterfall Model

1. Both the software development models are similar in most of the cases, it is just the
waterfall works in sequence and RAD works in a linear process, but mostly the end result
is same
2. RAD and Waterfall models can be used in the development of similar products
3. RAD was introduced for addressing the weaknesses in the Waterfall model
4. It would not be wrong to say that RAD is a much faster and enhanced version of the
Waterfall model.

OOP 8
Traditional Structure Methodologies versus Traditional Object Oriented Methodologies
Object Modelling Technique
OMT (Object Modelling Technique) is one of the methodologies of analysis and objectoriented design; it is far more efficient than traditional structure methodologies (Rumbaugh et.al,
1990). The great virtue that makes this methodology proficient is its characteristic of being open
source software, which makes it easily accessible for the public domain, and therefore, survives
with enormous vitality. This facilitates their evolution to fit all current and future needs of
software engineering.

Figure 3: Stages of Object Modelling Technique

Stages of Object Modelling Technique

Analysis: The analyst constructs a model of the problem domain, showing their most
important properties. The analysis model is an abstraction and accurate summary of what the

OOP 9
desired system should and what sort of functions should the desired system should not perform
and not the way how it will behave in case there are any issues. This phase ensures that model
elements are associated and developed while keeping the concepts of application domain in
consideration, except of the computer domains such as the data structures (Rumbaugh et.al,
1991). A good model should be able to be understood and criticized by experts in the problem
domain that do not have computer skills.
System design: The system designer making high level decisions about the architecture
of it. During this phase the system is organized into subsystems based on both the structure of the
analysis and the proposed architecture.
Design objects: The object designer builds a design model based on the analysis model,
but incorporating implementation details. Object design focuses on data structures and
algorithms that are necessary to implement each class. OMT describes how the design can be
implemented in different languages (oriented and non-object-oriented databases, etc.).
Implementation: The object classes and relationships developed during the analysis
objects are eventually translated into a concrete implementation. Thus, it is essential that during
implementation phase the various principles of the software engineering are kept in
correspondence with the design ensuring that the implemented system is flexible and extensible.

Structured Systems Analysis and Design Method

Structured Systems Analysis and Design Method (SSADM) is a systems approach for the
analysis and design of information systems. Many specialists in information systems recognize
the difficulty in understanding comprehensively large and complex systems (Siau, & Rossi,
2011). The method of development of structured analysis aims to overcome this difficulty by:
1. Dividing the system components

OOP 10
2. Building a model of the system
The analysis refers to the initial end of a systems development project during the time
that user requirements are defined and documented.
The structured analysis allows the analyst to know a system or process in a logical and
manageable way while providing the basis for ensuring that no relevant detail has been omitted.
The objective of structured analysis is to organize the tasks associated with the
determination of requirements for complete and accurate understanding of a given situation.

Figure 4: Stages of SSADM

Stages of SSADM
Requirements Specifications: The activities that are performed at this stage include the
diagramming of use cases which are a description of the sequence of interactions that occur
between an actor and the system when the actor uses the system to perform a specific task.

OOP 11
Analysis: In this phase a detailed description of the input and output of each use case
diagrams are presented. A sequence diagram shows an ordered interaction according to the
temporal sequence of events. In particular, it shows the objects participating in the interaction
and exchange messages sorted by time sequence. A collaboration diagram shows an interaction
organized based on the objects participating in the interaction and the links between them (in
terms of the interaction is concerned). In this stage the initial system interface is also defined,
which is done through a state diagram that shows the sequence of states through which passes a
use case or an object over your life, indicating which events make it pass from one state to
another and what are the responses and actions it generates. Along, with the description of the
validation methods for classes are presented (Ashworth, 2004).
Design the system: At these stage system components, applications and location are
defined with the help of node representing the components and active objects within nodes.
Along, with that the communication mechanisms are also defined through partnerships
dependency between nodes, components or applications and, if known, add a stereotype to define
the communication protocol required. Add notes with restrictions, expected performance and
other details of the connections. Finally, the architecture tis validated by checking the technical,
economic and organizational validity of the proposal.
Detailed Design: At this stage the analysis of the specific characteristics of the
implementation environment adapts and different system applications are completed with control
models. Complete details of classes, attributes, methods and associations design are presented at
this stage.
Implementation and testing: In this stage the final code is developed and tested. Tests
are perfumed on the final product using different testing module in order to determine the
efficiency of the software.

OOP 12

Similarities between OMT and SSADM

1. Both OMT and SSADM are classified as a specific problem solving methodologies.
2. Both OMT and SSADM integrates the processes and data for the development of
software
3. Both OMT and SSADM are used for the development of large software systems
4. Both OMT and SSADM have clearly defined procedures

Differences between OMT and SSADM

OMT
SSADM
OMT has a very high rate of reusability SSADM has a very limited rate of reusability
due to its ability of delegating and
inheriting objects
OMT is still new and can be termed as

It is a matured methodology which is widely spread.

SSADM is matured methodology, and is already in

an emerging methodology
use for the development of softwares by many
OMT is suitable to use for the project

organizations around the world.

SSADM is suitable to use for the project with stable

in which the requirements are changed

requirements

continuously
OMT emphasize on the objects

SSADM emphasize of the processes

OOP 13
Agile Software Development Methods
Agile Software Development is a paradigm of development methodologies based on agile
processes. Agile software development processes, formerly known as light methodologies, try to
avoid the tortuous and bureaucratic ways of traditional methodologies focusing on people and
results. The agile process uses a value-based approach for building software, collaborating with
customers extensively (Wang et.al, 2012).
It is a conceptual framework for software engineering that promotes development
iterations throughout the project life cycle. There are many methods of agile development; most
developing software minimizes risks in short periods of time. The Agile methods emphasize on
face-to-face communications through the documentation. Most agile teams are located in a single
office open. The office must include authors, designers iteration, help and documentation writers
and project managers. Following are the three agile software development methods
Scrum
Scrum
Scrum is a framework for project management. It is considered an agile framework for
Agile Software Development, even though Scrum can be applied to manage projects of virtually
any kind. Scrum is a process that includes a set of practices and predefined roles. Main roles in
Scrum are performed by the Scrum Master which is responsible for maintaining the processes
and tasks in a similar way to a Project Manager; The Product Owner (also called "Businessman")
who represents stakeholders (stakeholders) and is part of the company requesting the product;
and Scrum team members including developers.
During each sprint or iteration, a period of 2 to 4 weeks is decided by the team, in which
the team creates Product Increment, which is usable prototype software. It is important that the
prototype is functional, this means that the team can move on towards the nest steps.

OOP 14
The set of features that are added in each iteration are from the Product Backlog (or
simply backlog), on which a set of high-level requirements that have to be made sorted by
priority. What requirements are included in the backlog is determined at the planning meeting
each iteration. During this meeting the Product Owner informs the team of the items in the
backlog which are to be completed (Vlaanderen et.al, 2011).
After the completion of this process the team changes the updates the backlog, meaning
that the requirements are frozen for that iteration. There are many good implementations of
systems to attend a Scrum development. Others simply prefer a blackboard and notes in the form
of a "memo". One of the main advantages of Scrum method is that it is very easy to learn and
requires minimal effort to get started.

OOP 15

OOP 16
Figure 5: SCRUM development Process
Extreme Programming
Extreme programming (XP) is an approach to software engineering. It is the most
prominent of agile software development processes. Like the other agile software development
method extreme programming is also different from the various traditional software development
methods, since it lays more emphasis on adaptability in predictability. Proponents of XP consider
changing requirements on the fly is a natural, inevitable and even desirable aspect of project
development (Lu, & Lu, 2013). Believe that being able to adapt to changing requirements at any
point in the project life is better and more realistic than trying to define all requirements early in
the project and invest efforts then monitor changes in the requirements approximation.

Figure 6: Extreme Programming development Process

Test Driven Development
Test-driven development (TDD) is a programming practice that involves two set of
practices: Writing tests first (Test First Development) and refactoring (Refactoring). To perform
tests it generally uses unitary testing. In a TDD the developers first writes a test and verify that
the tests result in a failure. Once this process is complete the engineer moves to the next step
which is coding to overcome the test failure and then refactor the code written is implemented.

OOP 17
The purpose of test-driven development is to achieve a clean code that works. The idea is that the
requirements are translated into evidence, thus when the tests pass it will ensure that the
requirements are implemented correctly (Session, 2012).
TDD allows much more robust-design and is so often thought of as Design handled by
the tests. Accordingly, TDD design facilitates a more maintainable software development
through the notion of testing. These tests require reflection on the behaviour of code and how to
ensure it will work as intended. Most of the time, TDD code is relatively safe, without doubt, and
is quite simple.
The code that is safe and simple is easier to change the code that shows the opposite traits
as the complexity and fragility (Markovic et.al, 2011). What's more, because the code is written
with TDD supporting evidence, any change that breaks the code is discovered quickly. In
essence, the code written with TDD it is easier to change and easier to fix.

OOP 18

Figure 7: Test Driven Development Process

OOP 19
Part II

Case Study
The senior management of St Patricks has decided to develop an online system in order
to maintain scholarly activities of staffs. The purpose of the system will be to maintain records
enabling the staff to input records and update their progress on scholarly activities. The primary
user of the system will be the by vice-principle of research and enterprise. He will be the only
one allowed to track whether staff (agents ) received the requested resources to conduct their
activities and progress on the activities.
In order to successfully develop this system and capture all the requirements, as the
developer of the system, I will make use of unified modelling language and diagrams which
includes:

Use case diagram and scenario

Sequence diagram

Class diagram

Robustness diagram.
Database will be created to store all information essential for the efficient functioning of
the system. The database will be updated on regular basis to keep up with the changes in the
scholarly activities.

Functional Requirement
Following are some of the functional requirements of the system given to me by St
Patricks senior management:

Capturing agents data

Checking and validation of agents

Input records

Update progress

OOP 20

Tracking of agents activities

OOP 21

Use Case Diagram for St Patricks Staff Management System

Log In

Add Details

Display Details

Update Details
<< uses > >

Vice-Principle

Staff Members

Delete Details
<< uses > >
<< uses > >

Update Details

From the use case diagram above it can be illustrated that there are two actors that ate
associated with the system. First and the primary used is the vice-principle of research and
enterprise. Second are the staff members. There are five cases in the St Patricks staff
management system which are; Login, AddDetails, DisplayDetails, UpdateDetails and also
DeleteDetails, only the vice-principle is allowed to perform all these functions.

OOP 22
Class Diagram for St Patricks Staff Management System

Faculty Members

Agent
+Input Record
+Update
Progress
+get record
+display record
+add record
+update record

Vice-Principle
+Check Progress
+Check Resources
+Check-in date
+Send Resources

+FirstName
+LastName
+EmployeeID
+Department
+Gender
+Address
+Email
+Phone-no

+Get Record
+Display()
+Records()
+Add Resources()

Database
Form
+Thesis Title
+ Thesis ID
+ Principle Agent
+Co-Principle ID
+Abstract
+Aims and Objectives
+Rational
+References

+FacultyMember
Log-in
+Form
+retreiveFrom()
+getRecord()
+displayRecord()
+addRecord()
+addReferences
+updateRecord()

OOP 23

From the figure above it could be seen that the classes of the system consists of VicePrinciple, Agent, Faculty members, Form, and Database. Vice-Principle is the one who has the
control over the system and its activities. While the staff members can only view system records,
they can neither add nor update the records, that authority is only available for the vice-principle.

Sequence Diagram for the St Patricks staff management system

Log-In Page

User Validation

Database

Agent
Log-In to the System
Validate Agents (ID, password)

Agents ID: found password matched

Record Updation
Update saved
I Record Successfully Update

Agents update progress successful

OOP 24

Robustness Diagram

Homepage
WebDisplay

Log-in

Investigators
Enter Info
Database

OOP 25

Click Listing
Software Development
Methodology

Log-in Page

Validation

For the development of St-Patricks staff management system we will use ICONIXl; alightweight Industrial Development Software that is halfway between methodology RUP
Database

Listand
Viewer
Record
List
Record
(Rational Unified Process)
XP (eXtreme
Programming),
is a methodology simplified

compared to more traditional, which unifies a set of methods object-oriented in order to have
strict control over the entire life cycle of the product to perform, has a sequence of steps to
follow and clearly defines the activities developed in each stage of the life cycle of the project
use it.

ICONIX Features

The reason behind the selection of ICONIX for the development St-Patricks staff
management system is it ability of resolving cases suing the UML, which greatly simplifies the
process without losing documentation when leaving only what is necessary. This implies a
dynamic use of UML so that you can always use other diagrams in addition to the already
established if deemed appropriate. ICONIX is guided through use cases and follows a cycle of
iterative and incremental life (Rosenberg, & Stephens, 2011). The aim is that from the use cases the
final system is obtained. Following are the steps involved in the development of St-Patricks
online system:
1. Iterative and Incremental: During the development of domain model and defining use
cases several iterations will occur. The incremental life cycle will help us to develop the
product in parts so we can integrate them functionally. Iterative cycle life, in every
iteration cycle will be reviewed and improved product.
2. Traceability: Every step we take will be defined by a requirement traceability is defined
as the ability to continue a relationship between different software artefacts produced.

OOP 26
3. Dynamics of UML: It will provide a dynamic use of UML because it uses some UML
diagrams, without requiring the use of all, as in the case of RUP.

Fundamentals of processes

1. It must be flexible enough to adapt to different styles and types of problems.

2. We must support the form of staff (including prototyping and iterative / incremental
development).
3. It serves as a guide for less experienced
4. Exposes products upstream code standard and understandable manner.
5. Phases ICONIX methodology
6. Review of requirements / Requirements Analysis:
7. Identify in the real world, objects and all aggregation and generalization relationships
between them. It should analyse all part of the system requirements and these build the
class diagram representing the functional groups to structure the system under
development.

Tools

For the development of St-Patricks staff management system we will use the following
tools.
1. Domain Model: This refers to identify objects and real world things involved with our
system. (Static)
2. Use Case Model: It describes the actions or behaviour that a user performs within the
system. Comprising of actors, use cases and system.

OOP 27
3. User Interface Prototype: It involves creating a model or operating models work a system
in which analysts and customers must agree. (Dynamic / users become active participants
in development)

Preliminary Review / Analysis Design and Preliminary Design

In this phase from each use case will get a token use case (which does not belong to
UML) consists of a name, a description, a precondition that must be met before starting a postcondition that must meet at the end if exit successfully. It should describe the use cases as a main
flow of actions and may contain alternative flows and flows exception. We will ensure that we do
not waste much time with the textual description. We will ensure to use a consistent style that
suits the context of the project. Perform Robustness Diagram: is a hybrid between a Class
Diagram and Activity Diagram. It is a tool that allows us to capture the To Do and from that it
How to do it. Facilitates the recognition of objects and makes reading easier system. Helps
identify the objects involved in each use case.
Robustness diagram is divided into:
1. Boundary objects: Used by actors to communicate with the system.
2. Objects entity: Are the domain model objects.
3. Control objects: Is the union between the interface and the entity objects.
4. Class Diagram: Describes the structure of a system by showing its classes, attributes and
relationships between them

OOP 28
Critical Design Review / Design

At this stage all the elements that are part of our system are recognized. Sequence
Diagrams: displays the methods that take the classes in our system. By showing all alternate
courses we can take all our use cases. It must end the static model, adding the details of design in
the class diagram and check whether the design meets all requirements identified.

Implementation

This is the final phase in which the final software of St-Patricks staff management
system will be completed, which is then handed St-Patricks management. Finally, we will be
using component diagram if necessary to support the development, i.e. show a physical
distribution of the elements of the internal structure of the system, and write and generate the
code. But also must take into account factors such as:
1. Reusability: The possibility to make use of components in different applications.
2. Extensibility: Is easily modifying the software.
3. Reliability: Systems performing discarding the possibility of error.
4. Testing: Test of units, cases, data and results. Integration tests with users to verify
acceptance of the results.

OOP 29

Figure 8: ICONIX PROCESS

Implementation of ICONIX Methodology to St-Patricks online system

Implementation of the ICONIX methodology in the development of St-Patricks staff

management system will ensure that all sort of unnecessary ambiguities are eliminated from the
system, and a successful robust system is developed. Keeping the initial objectives in
consideration following are the objects that were identified for the development of St-Patricks
online system

Management

Agents (staff)

Principle investigator

Vice-principle

Form 1

Records

OOP 30

Progress update

Requested resources

Progress activities

Scholar activities

After the successful implementation of the ICONIX process, the objects were reduced by
the elimination of the all the unnecessary objects. Below are the new sets of objects for the StPatricks staff management system

Vice-principle

Verification

Agents

Update Activities

Input Record

Form

OOP 31

ST-PATRICKS ONLINE DOMAIN MODEL

Agents

Submit

Form

view

Vice-principle

Input
Records

verify

Verifies

Update
Update
Activities

Track
Agents
activities

Fig 9: New Updated Domain Model

Testing

The quality assurance processes of a software product are often divided with regard to
their analytical component in static and dynamic tests. The fundamental difference between these
types of tests, is that the static tests focus on assessing the quality with which it is generating
project documentation, through periodic reviews, while the dynamic tests, require the execution
of software to measure the level of quality with which this was coded and the level of
compliance in relation to the system specification.
Perform dynamic testing a software product, usually in most cases confused with a
simple activity test execution and reporting of incidents, however, for products of medium
complexity on, it is advisable to formally implement methodology evidence that fits and fit
evenly with the development methodology selected by the development firm.

OOP 32
For processes based on RUP or traditional development methods, implement a testing
methodology is entirely feasible, given that these methodologies are oriented to documentation
and formalization of all activities performed. If, however, the development firm guide your
process under guidelines based on agile methodologies will need to reassess whether to execute
all activities involving a process of formal testing, which in most cases leads to minimize
activities related to the process of testing, a fact which can naturally trigger the release of
products with low quality.
Finally after the final product is developed, which the St-Patricks staff management
system the next phase will be to perform various tests on the system in order to determine the
efficiency of the system. For the St-Patricks staff management system the bellow test case will
be carried out in order to verify if the system meet the requirements.
N
O
1

CASE
TESTED
Registration of
the Agent

DATA TESTED

ACTUAL
RESULT
successful

REMARK

Duplicated
registration

First Name:
Email already
Last Name:
exist
Gender: female
Department: Science
Email:
Password: sec321

Email already
exist

Pass

Vice-principle

First Name:
Last Name:
Gender: Female
Department:
Management:
Email:
Password:

Successful

Pass

First Name:
Last Name:
Gender: female
Department: Science
Email:
Password:sec321

EXPECTED
RESULT
Successful

Successful

Pass

OOP 33
4

5
6

Check if
agents received
requested
resources
Agents
activities
progress
Track agents
activities

Select requested
resources list from
menu

System generate
delivery report
email

Delivery
report email
confirmed

Pass

Select progress list

from menu

Upload activities
progress

Pass

Select progress list

from menu

Recent progress
list displayed

Upload
activities
progress
Current
progress list
displayed

pass

OOP 34

References
Ashworth, C. M. (2004). Structured systems analysis and design method (SSADM). Information
and Software Technology, 30(3), 153-163.
Beynon-Davies, P., Carne, C., Mackay, H., & Tudhope, D. (1999). Rapid application
development (RAD): an empirical review. European Journal of Information
Systems, 8(3), 211-223.
Gilb, T. (1985). Evolutionary delivery versus the waterfall model. ACM SIGSOFT Software
Engineering Notes, 10(3), 49-61.
Laplante, P. A., & Neill, C. J. (2004). The demise of the Waterfall model is
imminent. Queue, 1(10), 10.
Lu, W., & Lu, L. (2013). Extreme Programming Project Performance Management by Statistical
Earned Value Analysis. Global Journal of Business Research, 7(5), 115-120.
Mackay, H., Carne, C., Beynon-Davies, P., & Tudhope, D. (2000). Reconfiguring the user: using
rapid application development. Social Studies of Science, 30(5), 737-757.
Markovic, D., Jovanovic, Z., Pesovic, U., & Randic, S. (2011, November). Test-Driven
Development (TDD) in development of measure application and transducers services.
In Telecommunications Forum (TELFOR), 2011 19th (pp. 1316-1319). IEEE.
Rosenberg, D., & Stephens, M. (2011). Iconix Process Roadmaps: Step-by-step Guidance for
SOA, Embedded, and Algorithm-intensive Systems. Fingerpress.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. E. (1991).Object-oriented
modeling and design (Vol. 199, No. 1). Englewood Cliffs, NJ: Prentice-hall.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1990). Object Modeling
Technique.
Session, S. E. S. (2012). Test-Driven Development.
Siau, K., & Rossi, M. (2011). Evaluation techniques for systems analysis and design modelling
methodsa review and comparative analysis. Information Systems Journal, 21(3), 249268.

OOP 35
Vlaanderen, K., Jansen, S., Brinkkemper, S., & Jaspers, E. (2011). The agile requirements
refinery: Applying SCRUM principles to software product management. Information and
Software Technology, 53(1), 58-70.
Wang, X., Conboy, K., & Cawley, O. (2012). Leagile software development: An experience
report analysis of the application of lean approaches in agile software
development. Journal of Systems and Software, 85(6), 1287-1299.