Assignment Work Proposal And Methodologies Comparison For Information System Development

Task 1

Iterative or agile methodologies of system development involve developing the system in increments and repeating the process for all increments until the whole system is complete and the customer is satisfied with the end product. Iterative or incremental development approach solves many problems experiences in the waterfall model. The basic concept of incremental development of a system is to divide the project into parts and those parts are further subdivided into sub-parts and then developed incrementally thus allowing developers to learn from the previous increments developed throughout the system development cycle. The iterations are sometimes referred to as sprints where by the sprints are allocated to individual in a project development team. There are two methodologies of iterative development discussed in this section, these methodologies are;

• Extreme programming
• Rational unified process.

Extreme programming is a software development methodology that mainly aims at emphasizing delivery of the expected software system that will suit its intended business operations amidst of changing customer requirements (Rouse, 2008). Extreme programming encourages team work and effective commination among the development team as it takes an incremental approach of continuous testing and revision of the increments developed (Jeffries, 2011). While undertaking the project, the customer of the project is an integral part of the team as the solution is aimed at meeting the laid out requirements of the customer. Extreme programming uses planning to determine what increments will be done and these increments are incrementally developed while continuous testing is done.

Extreme programming encourages a lot of team work and constant effective communication to ensure that everyone is responsible for their pieces of code and that every team member in the development team is following the laid out programming pattern to make it easy for all team members to understand each other’s code. Every team member has to have an image of what the overall system looks like and how it is intended to work to meet all the requirements laid out by the customer. The following diagram gives a conceptual view of how extreme programming works in an organization.

Figure 1: Extreme programming core practices.

The core practices of extreme programming are;

• Whole team- All stakeholders in the project are supposed to sit together to define and plan for the project. The stakeholders might include the customer who might have an end user who has an in depth overview of what is going to be taking place. There are also developers and testers who will be developing the system. Everyone in the whole team is supposed to contribute in any way that they can.
• Planning game-  planning game practices addresses two issues;
• Prediction of what is expected on a certain date
• Determining of what is supposed to be done next.

There are two types of planning in this practice;

• Release planning- Customer produces desired features he is expecting from the system to the development team.
• Iteration planning- the development is given deliverables every two weeks
• Customer tests- A customer defines acceptance tests for every deliverable.
• Small releases – team release a tested software meeting customer requirements for every iteration and the XP team releases to the end users on a frequent basis.
• Pair programming- two programmers make every feature in XP.

Rational unified process (RUP) is an object oriented programing methodology. It’s also web enabled. Fundamentally RUP is intended to provide a specific model of implementation of approaches that are commercially proven for use throughout the whole software development life cycle (SDLC) (Morse, 2017). Rational unified process was not originally designed as a concrete development model but was developed to adapt and fit to the specific needs of a project, team or organization. RUP is based on development phases and the building blocks that define when, what and how the development of the project will take place.

The fundamental best practices of the rational unified process are demonstrated on the diagram below;

Figure 2: rational unified process fundamental best practices 

These fundamental best practices can be looked at as;

• Developing the software iteratively- iterative development is highly encouraged by identifying high risk elements of every phase of the software development life cycle.
• Management requirements- Organization of all functional requirements, business requirements, documentation and decisions and tradeoffs.
• Used component based architectures- Encourages development through creation of components that can be reusable throughout the whole development life cycle.
• Visually model software- modelling the software based on UML.
• Verify software quality- Helps come up with the test and specifies how to implement and evaluate the tests throughout the SDLC.
• Control changes to the software- helps keep in management and tracking of all requirements that arise throughout the development.

Rational unified process operates in 4 phases

• Inception phase -determining of the basic structure of the project.
• Elaboration phase – analyzing of the project requirements and the project architecture.
• Construction phase -coding and implementation of the proposed features.
• Transition phase- Transition phase- deployment of the end product of the customers

Category	Rational Unified process	Extreme Programming
Type	Iterative	Agile: Iterative and Incremental
Iteration length	Long	Short
Activities	Inception phase Risk Analysis Elaboration phase Construction phase Transition phase	Coding Testing Listening Designing
User involvement in All SDLC phases	No	Yes
Complexity of System	Medium	Medium
Well defined requirements	Yes	Yes
Reusable components	Yes	Yes
Expertise of the user in problem domain	Very less	Adequate
Project size	Suitable for a large project	Small to medium
Requirements change responsiveness	Track and manage any requirements that arise throughout the SDLC	Very fast
End of project	Defined at late stages	End the project in a short period
Number of iterations	Unknown (slow)	Fast even with more iteration
Project team	Small or Large	Small (2-12)
Software Delivery	Long period (months)	Short period (2 weeks)
Weaknesses	– Risk analysis need expertise – Requires experts to understand all the components needed in a system	-It doesn’t measure the plan quality aspect -Code centric rather than design -Not structured -Hard to do extreme programming

Task 2

The recommended methodology to be used in development of the mine pump monitoring and control systems is rational unified process. This is the best methodology to use while developing the project because it makes it easy to deal with changing requirements throughout the SDLC and because it also has a strong emphasis on accurate and proper documentation. RUP also enables integration throughout the SDLC.

Requirements of an information system is what the user expects that system to do and how to do it. There are various ways of gathering requirements from different user of the system and doing a software analysis to come up with a specifications documents. The whole process is of gathering requirements and analyzing them is called requirements engineering.

The various techniques of requirements gathering are;

• Interviews- There are two types of interviews used in requirements gathering;
• One-to-one interviews- this type of interview is held by only two stakeholders i.e. the interviewer and the interviewee where by the interviewer interviews the interview who may be the user of a system to come up with requirements. It require planning and preparation in order to come up with the type of questions or engagement that is going to be used to be used on the interviewee.
• Group interviews- this type of interviews comprises of an interview and a group of interviewees where by the interviewees are classified into their respective departments and interviews are done on those groups. This type of interview can obtain a lot of information within a very short time as compared to the one-to-one interviews.
• Workshops- this method of requirements gathering involves holding a workshop with all involved stakeholders and working together to come up with the requirements. The workshops are mostly for a specified time and can bring more and better outcome as compared to group interviews. The major drawback with workshops is that the method requires a lot of preparation and facilitation in order to hold workshop.
• Use of requirements gathering tools- Requirements gathering tools for example Axia’s RFI/RFP templates are tools comprising of a template with all the possible requirements of the system which is distributed to all stakeholders. The stakeholders are supposed to choose the requirements they see fit the system according to their own capacity of how they understand the proposed system. This method is a very fast technique of obtaining requirements but can be exploited by some users where by some users can tick requirements they don’t necessarily need or don’t even understand.
• Brainstorming- Brainstorming is method of requirements gathering which can be done individually or by a group. The main aim is to brainstorm and come up with ideas while noting them down and then ideas are reviewed and analyzed to come up with the system requirements. This method can generate a lot of innovative and tangible requirements for the project but may be a problem if users are not willing to brainstorm as some people find brainstorming to be cumbersome.
• Feasibility study- This method of requirements gathering involves studying existing systems and the possibility of the existing being replaced. This technique involves documenting the findings thus it’s easy to review the documentation to come up with the requirements.
• Review of the documentation of the current system – this technique of requirements gathering involves reviewing documentation for the current system in use to identify the missing requirements and the existing requirements. The documentation of this systems may include; software vendor manuals, interface details or user manuals. This method of requirements gathering can bring about a lot of tangible requirements but sometimes existing documentation may be out of date and very old thus might not be very helpful making this technique unreliable in that case.
• Questionnaires- This technique of requirements gathering involves distributing a questionnaire to the involved stakeholders. The stakeholders are supposed to answer the questionnaire and then return it for analysis to come up with the requirements. Questionnaires can be distributed in form of physical papers, web forms or even could even be verbal. This techniques is often sees as an easy method f requirements gathering because many users find it easy to identify what they want based on the question asked which gives them a view of what the requirement can be. However, a questionnaire requires a lot of time to prepare to come up with good questions.
• Observing- Observing is a technique of requirements gathering where by the system analysts visit the place of business to observe operations in order to come up with the requirements based on the business processes they observer during the observation process. In some cases, the system analysts can do the actions themselves for them to get a better insight of that specific business process.
• Prototyping- This is a technique of requirements gathering that involves collection of requirements and using them to come up with a prototype. The prototype is then implemented on a temporary basis enabling the users to get a view of how the system will be and in what way it will behave, thus they can be able to give clear requirements because they already know what the system is capable of.

Functional requirements are actions that the system is expected to perform by its users (Erikson, 2012). According to the case study, the following functional requirements were identified;

Functional Requirement	Input	Process	Output
Read high level water sensor	No input	The system should use the high water sensor to determine when the water level is too high so that it can start pumping.	-Running water pump
Read low level water sensor	No input	The system should use the lower water sensor to determine when the water level is low enough for it to stop pumping	-stopped water pump
Operator authentication	-Username -password	The system should authenticate an operator using a username and a password	-Session created
Switch water pump on	-water level	The system should allow the operator to switch on the pump only when the high water sensor indicates that the water level is high	Running water pump
Switch water pump off	No Input	The system should allow an operator to switch off the pump when the low water level indicates that the water level is down enough	Switched off water pump
Supervisor authentication	-username -password	The system should authenticate a supervisor using a username and password	-session created
Switch pump on or off	No input	The system should allow the supervisor to switch the pump on or off no matter what both high water lever and low water level sensors are showing	Running water pump or stopped water pump
Adding note to event log	Notes: STRING	The system should allow the supervisor to add a note to an event log	-log notes updated
Trigger alarm	No input	The system should read the methane sensor and trigger the alarm if the methane levels are off. The system should also stop the water pump if it  is running	-triggered alarm -stopped water pump
Event logging	No input	The system should save vents such as, Pump switched on by high water sensor , Pump switched off by low water sensor , Pump switched on or off by operator or supervisor , Evacuation alarm triggered by methane sensor and the reading of the methane sensor every 30 minutes.	Logs updated

Non-functional requirements are requirements that specify how the proposed system is supposed to perform functional requirements by showing how the system is supposed to function and the limit of the system when executing the system. The following non-functional requirements were observed of the system;

• Performance- Performance of the application specifies how fast the application is supposed to perform various functions
• Reliability- Reliability describes the robustness of the system where by the system analyst identifies how reliable the system is amidst presence of problems.
• Availability- availability of a system specifies how long the system is expected to be up. This is basically the uptime. For the proposed system uptime is a critical factor where by the system is expected to be uptime all the time because of it goes down many lives are a stake.
• Recoverability- Recoverability of the system is the ability of the system to recover after a crush or a failure. The recoverability of the system is crucial for the proposed system because the system is expected to be up all the time.
• Usability- Usability of the system is the how easy to use the system will be. The proposed system is expected easily usable.
• Security- The proposed system application should be secure to ensure malicious users do not get access to the application to cause more harm.

Non Functional Requirement	Description	Related To
Performance	Performance of the application specifies how fast the application is supposed to perform various functions	Quality
Reliability	Reliability describes the robustness of the system where by the system analyst identifies how reliable the system is amidst presence of problems	Quality
Availability	Availability of a system specifies how long the system is expected to be up. This is basically the uptime. For the proposed system uptime is a critical factor where by the system is expected to be uptime all the time because of it goes down many lives are at stake	Quality
Recoverability	Recoverability of the system is the ability of the system to recover after a crush or a failure. The recoverability of the system is crucial for the proposed system because the system is expected to be up all the time	Quality
Usability	Usability of the system is the how easy to use the system will be. The proposed system is expected easily usable	Quality
Security	The proposed system application should be secure to ensure malicious users do not get access to the application to cause more harm	Quality

Use case analysis shows how different actors interact with the system. For this case study, the actors can be objects like the sensors which interact with the system.

Figure 3: Use case diagram

Use case name:	Login	Use case ID:	UC-1
Description :	The login use case starts when the operator wants to access the system whereby they are supposed to login by producing their username and password and if authentication is correct then a session is created
Author:	Wafaa Salim Al Sudiri
Actors:	operator
Location	Oman Mines
Status	Pathway Defined
Priority:	1
Assumptions:	Operators has to use a computer connected to the network on which the system is running
Pre-Condition:	Operator has a predefined username and password
Post-Condition:	Operator will granted session to the system
Primary Path: (Happy)	A session is created and the operator can access the system
Alternate Path:	– An operator may not be authenticated because of invalid login credentials
Exception Path:	– An operator has login using any computer in the network
Happy Path Flow of Events	1- Operator opens the login window 2- Operator enters his username and password 3- Operator is granted session if the password and username are correct 4- Operator is denied access if the username and password are not correct.

Use case name:	Start pump	Use case ID:	UC-3
Description :	An operator or high water level subsystem starts the pump based on the reading from the high water level sensor.
Author:	Wafaa Salim Al Sudiri
Actors:	Operator, high water level subsystem
Location	Oman Mines
Status	Pathway Defined
Priority:	1
Assumptions:	The high water level subsystem is external to the main system
Pre-Condition:	The sensor has water level has to be high than the normal amount
Post-Condition:	The pump will start pumping water
Primary Path: (Happy)	The water pump is started.
Alternate Path:	– Supervisor starts the pump
Exception Path:	– the operator can start pump using any computer in the network
Happy Path Flow of Events	1- Operator gets the reading of the sensor 2- Operator starts the pump 3- System checks for water level; if water level is too high system starts pump, if water level is too low system deos not start pump.

Use case name:	Stop pump	Use case ID:	UC-4
Description :	An operator or low water level subsystem stops the pump based on the reading from the low water level sensor.
Author:	Wafaa Salim Al Sudiri
Actors:	Operator, low water level subsystem
Location	Oman Mines
Status	Pathway Defined
Priority:	1
Assumptions:	The lower water level subsystem is external to the main system
Pre-Condition:	The sensor has to verify the water level is low
Post-Condition:	The pump will stop pumping water
Primary Path: (Happy)	The water pump is stopped.
Alternate Path:	– Supervisor stops the pump – Methane sensor subsystem stop the pump.
Exception Path:	– the operator can stop pump using any computer in the network
Happy Path Flow of Events	1- Operator gets the reading of the sensor 2- Operator stops the pump 3- System checks for water level; if water level is low enough system starts pump, if water level is high system does not start pump.

Use case name:	Login	Use case ID:	UC-5
Description :	The login use case starts when the supervisor wants to access the system whereby they are supposed to login by producing their username and password and if authentication is correct then a session is created
Author:	Wafaa Salim Al Sudiri
Actors:	supervisor
Location	Oman Mines
Status	Pathway Defined
Priority:	1
Assumptions:	Supervisor has to use a computer connected to the network on which the system is running
Pre-Condition:	Supervisor has a predefined username and password
Post-Condition:	Supervisor will be granted session to the system
Primary Path: (Happy)	A session is created and the Supervisor can access the system
Alternate Path:	– An Supervisor may not be authenticated because of invalid login credentials
Exception Path:	– An Supervisor has login using any computer in the network
Happy Path Flow of Events	1- Supervisor opens the login window 2- Supervisor enters his username and password 3- Supervisor is granted session if the password and username are correct 4- Supervisor is denied access if the username and password are not correct.

Use case name:	Start pump	Use case ID:	UC-6
Description :	An supervisor starts the pump without reading from the high water level sensor.
Author:	Wafaa Salim Al Sudiri
Actors:	supervisor
Location	Oman Mines
Status	Pathway Defined
Priority:	1
Assumptions:	The supervisor can be bypass the sensor readings
Pre-Condition:	Pump is not running
Post-Condition:	The pump will start pumping water
Primary Path: (Happy)	The water pump is started.
Alternate Path:	– The pump is started by the operator or the high water level subsystem
Exception Path:	– the supervisor can start pump using any computer in the network
Happy Path Flow of Events	1- Operator starts the pump 2- System starts up the pump without checking sensor readings

Use case name:	Stop pump	Use case ID:	UC-7
Description :	A supervisor methane level subsystem stops the pump without getting sensor reading from the sensors
Author:	Wafaa Salim Al Sudiri
Actors:	supervisor, methane level subsystem
Location	Oman Mines
Status	Pathway Defined
Priority:	1
Assumptions:	The water pump is stopped unexpectedly incase of emergencies.
Pre-Condition:	The water pump has to be running
Post-Condition:	The pump will stop pumping water
Primary Path: (Happy)	The water pump is stopped.
Alternate Path:	– Operator stops the pump – Low water level subsystem stop the pump.
Exception Path:	– the supervisor can stop pump using any computer in the network
Happy Path Flow of Events	1- Supervisor or methane level subsystem stops the pump 2- System stops the pump without checking the sensor readings

Use case name:	Trigger evacuation alarm	Use case ID:	UC-8
Description :	Methane sensor senses high methane levels and triggers the evacuation alarm.
Author:	Wafaa Salim Al Sudiri
Actors:	methane level subsystem
Location	Oman Mines
Status	Pathway Defined
Priority:	1
Assumptions:	The methane levels have to be high for the evacuation alarm to triggered
Pre-Condition:	The sensor has to show methane levels are high than the recommended level.
Post-Condition:	The evacuation alarm will be triggered
Primary Path: (Happy)	The evacuation alarm starts ringing.
Alternate Path:
Exception Path:
Happy Path Flow of Events	1- Methane level subsystem gets reading from the sensor 2- Methane level subsystem sends the information to the system. 3- The system triggers an alarm.

Before startup of any project, the resources to be used during the system development have to be defined. These resources include both hardware and software resources that will be used during the development of the project. The software tools are nontangible but are required to be used alongside the hardware resources.

For the software to be used, first of all there is need for an operating system on which all the other software’s will run on. Windows 7 is the operating system that will be used during the development. For the programming language, C is going to be used. The reason for choosing C is because the project involves development of an embedded system and C is the ideal language to use when programming hardware. The IDE to be used is Falcon C/C++.

Hardware are the physical components on which the software will run on. To run windows 7 a desktop computer with an Intel Core i3 and above processor, 6GB and above memory and 250GB hard disk can be used to run the operating system. Since the system being developed is an embedded system, a high water level sensor and low water level sensor have to be purchased. A methane level sensor is required. Each of the sensor is its own subsystem thus a microcontroller is needed to issue instructions to the main system. For this, each sensor will use an Arduino Uno. The system will also need a piezo buzzer for the alarm which will be triggered by the methane level sensor to make noise (Bruce, 2013).

Task 3

For the modelling technique Unified Modelling Language (UML) will be used to give a conceptual view of the system. A class diagram is modelled to show the classes of the system and how they interact within the underlying architecture of the proposed system.

As discusses on Section 2 which is Task 2 of the assignment, the methodology to be used is Rational Unified Process (RUP) which will allow creation of components which can be reused throughout the project life cycle. This method is preferred because it supports object oriented programming.

Figure 4: Class diagram

After evaluation of the UML class diagram the project can be improved through various ways. The main concept of the application is an embedded system that is linked with an information system through which an operator and a supervisor can view information read by the subsystems and take appropriate action. My proposal was, instead of each sensor having its own Arduino Uno Microprocessor, all the subsystems could be integrated into one embedded system using one Raspberry processor (Browning, 2012), for example the system could use Raspberry Pi 3 which has the following specifications;

• SoC: Broadcom BCM2837 (roughly 50% faster than the Pi 2)
• CPU: 1.2 GHZ quad-core ARM Cortex A53 (ARMv8 Instruction Set)
• GPU: Broadcom VideoCore IV @ 400 MHz.
• Memory: 1 GB LPDDR2-900 SDRAM.
• USB ports: 4.
• Network: 10/100 MBPS Ethernet, 802.11n Wireless LAN, Bluetooth 4.0.

Using one processor would help integrate the system into one unit from where all operations are done. Raspberry Pi 3 comes preloaded with python thus using this controller can help create a more intelligent system which requires human intervention in minimal cases.

The best database to use for the system is a relational database. Relational databases are preferred for this system because they are easy to understand and implement and their ability to store large amount of data which is interrelated meaning the querying and retrieval is a very fast process which does not consume a lot of time. Use of MySQL database can be a good move but the relational database to use is Oracle 11g database. This is because oracle databases are very secure and stable. Security being one of the most crucial non0functional requirement of the system makes oracle 11g the better preference because oracle 11g will enforce security up to 3 tier levels of the application

UML modeling technique is still the best model to use through the software development life cycle (SDLC). This is because UML enhances a greater understanding of the system to both the client and the development team. For the client UML modeling will help the client get a better understanding of what the system is supposed to do for them, i.e. the clients gets a better understanding of the functional requirements of the system. For the development team use of UML models will help give a clear understanding of the static and the dynamic structure of the proposed system thus simplifying the development process.

Conclusion

Procuring an information system requires high involvement and communication among all the involved stakeholders. The stakeholders can range from the clients both corporate and technical and the development team. This is done to ensure that both teams get both a conceptual and in depth understanding of the system. This document has demonstrated techniques that can help simplify different phases of the software development life cycle. For example a client may get a better understanding of the system by looking at the use case diagram while the developer will get the static structure of the system using a class diagram.

References

Browning, J., 2012. So you got a Raspberry Pi: now what? engadget. Available at: https://www.engadget.com/2012/09/04/raspberry-pi-getting-started-guide-how-to/ [Accessed August 25, 2017].

Bruce, J., 2013. How To Make a Simple Arduino Alarm System. MakeUseOf. Available at: https://www.makeuseof.com/tag/how-to-make-a-simple-arduino-alarm-system/ [Accessed August 25, 2017].

Erikson, U., 2012. FUNCTIONAL REQUIREMENTS VS NON FUNCTIONAL REQUIREMENTS. reqtest. Available at: https://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/ [Accessed August 25, 2017].

Jeffries, R. 2011. What is Extreme Programming? ronJeffries. Avaialble at: https://ronjeffries.com/xprog/what-is-extreme-programming/ [Accessed August 25, 2017].

Morse, A.P., 2017. Rational Unified Process: What Is It And How Do You Use It? airbrake. Available at: https://airbrake.io/blog/sdlc/rational-unified-process [Accessed August 25, 2017].

Rouse, M. 2008. Extreme Programming (XP).TechTarget. Available at: https://searchsoftwarequality.techtarget.com/definition/Extreme-Programming [Accessed August 25, 2017]

Rouse, M. 2007. Rational Unified Process (RUP) TechTarget. Available at: https://searchsoftwarequality.techtarget.com/definition/Rational-Unified-Process  [Accessed August 25, 2017]