Running Head: OOP

Application Engineering

[Name of the Writer]

[Name of Institution]

[Dated]

OOP ii

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

Differences between OMT and SSADM.................................................................................15

Agile Software Development Method’s..................................................................................16

Scrum..............................................................................................................................16

Extreme Programming....................................................................................................18

Test Driven Development................................................................................................19

Part II.............................................................................................................................................21

Case Study..............................................................................................................................21

Functional Requirement.........................................................................................................21

Use Case Diagram for St Patrick’s Staff Management System..............................................23

Class Diagram for St Patrick’s Staff Management System....................................................24

Sequence Diagram for the St Patrick’s staff management system.........................................25

Robustness Diagram...............................................................................................................26

Software Development Methodology......................................................................................26

ICONIX Features............................................................................................................27

Fundamentals of processes.............................................................................................28

OOP iii

Tools................................................................................................................................28

Preliminary Review / Analysis Design and Preliminary Design....................................29

Critical Design Review / Design.....................................................................................30

Implementation................................................................................................................30

Implementation of ICONIX Methodology to St-Patrick’s online system...............................31

ST-PATRICK’S ONLINE DOMAIN MODEL........................................................................33

Testing....................................................................................................................................33

References......................................................................................................................................36

OOP 4

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.

OOP 5

Figure 1: Waterfall Model

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.

OOP 6

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.

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.

 

OOP 7

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.

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.

OOP 8

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.

Figure 2: RAD Model

OOP 9

Difference between RAD Model and Waterfall Model

RAD Waterfall

It is a linear software process It is a sequential software development process

During the planning, analysis, and the testing

heavy involvement of the customers are

required

During the planning, analysis, and the testing

phase heavy involvement of the clients are

required

Not Favourable under situations where batch

processes are required

Beneficial under situations where batch

processes are required

It is all about building relevant systems 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 10

Traditional Structure Methodologies versus Traditional Object Oriented Methodologies

Object Modelling Technique

OMT (Object Modelling Technique) is one of the methodologies of analysis and object-

oriented 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

OOP 11

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

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.

OOP 12

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

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.

OOP 13

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.

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

OOP 14

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 15

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

due to its ability of delegating and

inheriting objects

SSADM has a very limited rate of reusability

OMT is still new and can be termed as

an emerging methodology

It is a matured methodology which is widely spread.

SSADM is matured methodology, and is already in

use for the development of software’s by many

organizations around the world.

OMT is suitable to use for the project

in which the requirements are changed

continuously

SSADM is suitable to use for the project with stable

requirements

OMT emphasize on the objects SSADM emphasize of the processes

OOP 16

Agile Software Development Method’s

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, designer’s 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.

OOP 17

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.

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 18

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.

OOP 19

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.

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.

OOP 20

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.

Figure 7: Test Driven Development Process

OOP 21

Part II

Case StudyThe senior management of St Patrick’s 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 RequirementFollowing are some of the functional requirements of the system given to me by St

Patrick’s senior management:

• Capturing agents data

OOP 22

• Checking and validation of agents

• Input records

• Update progress

• Tracking of agents activities

OOP 23

Use Case Diagram for St Patrick’s Staff Management System

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 Patrick’s staff

management system which are; Login, AddDetails, DisplayDetails, UpdateDetails and also

DeleteDetails, only the vice-principle is allowed to perform all these functions.

Log In

Add Details

Display Details

Update Details

Delete Details Vice-Principle Staff Members

Update Details

<< uses > >

<< uses > >

<< uses > >

OOP 24

Class Diagram for St Patrick’s Staff Management System

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

Vice-Principle

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

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

Form

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

Faculty Members

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

Database

+FacultyMember Log-in+Form

+retreiveFrom()+getRecord()+displayRecord()+addRecord()+addReferences+updateRecord()

OOP 25

From the figure above it could be seen that the classes of the system consists of Vice-

Principle, 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 Patrick’s staff management system

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

Database User ValidationLog-In Page

OOP 26

Robustness Diagram

Investigators

Log-in

Enter Info

Homepage

WebDisplay

Database

OOP 27

Software Development Methodology

For the development of St-Patrick’s staff management system we will use ICONIXl; a-

lightweight Industrial Development Software that is halfway between methodology RUP

(Rational Unified Process) and 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-Patrick’s 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-Patrick’s

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 artefact’s produced.

Validation Log-in Page Click Listing

DatabaseList Viewer Record List Record

OOP 28

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-Patrick’s 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 29

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 post-

condition 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 30

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-Patrick’s staff management

system will be completed, which is then handed St-Patrick’s 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 31

Figure 8: ICONIX PROCESS

Implementation of ICONIX Methodology to St-Patrick’s online system

Implementation of the ICONIX methodology in the development of St-Patrick’s 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-Patrick’s

online system

• Management

• Agents (staff)

• Principle investigator

• Vice-principle

• Form 1

OOP 32

• Records

• 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 St-

Patrick’s staff management system

• Vice-principle

• Verification

• Agents

• Update Activities

• Input Record

• Form

OOP 33

ST-PATRICK’S ONLINE DOMAIN MODEL

Submit view

Input

verify Update

Track

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

Agents Vice-principle Form

Records

Update Activities

Agent’s

activities

Verifies

OOP 34

complexity on, it is advisable to formally implement methodology evidence that fits and fit

evenly with the development methodology selected by the development firm.

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-Patrick’s 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-Patrick’s staff management system the bellow test case will

be carried out in order to verify if the system meet the requirements.

NO

CASE TESTED

DATA TESTED EXPECTED RESULT

ACTUAL RESULT

REMARK

1 Registration of the Agent

First Name:Last Name:Gender: femaleDepartment: ScienceEmail:Password:sec321

Successful successful Pass

2 Duplicated registration

First Name:Last Name:Gender: femaleDepartment: ScienceEmail:Password: sec321

Email already exist

Email already exist

Pass

3 Vice-principle First Name:Last Name:

Successful Successful Pass

OOP 35

Gender: FemaleDepartment: Management:Email:Password:

4 Check if agents received requested resources

Select requested resources list from menu

System generate delivery report email

Delivery report email confirmed

Pass

5 Agents activities progress

Select progress list from menu

Upload activities progress

Upload activities progress

Pass

6 Track agents activities

Select progress list from menu

Recent progress list displayed

Current progress list displayed

pass

OOP 36

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.

OOP 37

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

methods–a review and comparative analysis. Information Systems Journal, 21(3), 249-

268.

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.