Essay: Assignment Work Proposal And Methodologies Comparison For Information System Development.

Task 1

Submit a work proposal for this assignment by 5th of August, 2017 (11:55 pm) which must include;

Expected Deliverables of the assignment [The deliverables are the specific work products that student must produce in order to complete the assignment. Example: For a business analysis assignment, deliverables could be business analysis plan, feasibility report, business requirement specification etc.]

Approach towards the solution [Specify the Literature, Software and Hardware needed to meet the assignment objectives]

Potential risks foreseeable [Technical risk, Management risk, External risk etc.]

Timeline and work breakdown (Gantt chart):

Task 2

Compare and Contrast any two well proven methodologies used for information systems development belonging to the categories of Iterative and Agile. You are required to propose an appropriate situation/requirement suits to implement your selected methodologies within the context of the given scenario. Your discussion points/ findings should be furnished as a write up with 300 words of your own apart from the referred contents.

Task 3

Critically evaluate the various options available for requirement capturing within the context of an information system development project. List down various functional and non-functional requirements of the scenario given.

Task 4

Perform a use case analysis for the scenario provided. You are required to produce an appropriate Use Case Diagram of the whole system with all the use case relationship along with Use Case Specification for the Use Cases identified.

Task 5

Produce a proposal for the tools and techniques for the design, and development of an information system for the scenario provided. Your proposal should have the recommendation of an appropriate development methodology, modeling technique and development tool. Your recommendations should be justified with adequate supporting points. Your proposal should be furnished as a write up with 200 words of your own apart from the referred contents.

Task 6

Design a class diagram for developing an information System for the scenario provided. Your class diagram should produce a static architectural view of the proposed information system for the scenario. You are required to provide appropriate role names and multiplicities for the relationships in the class diagram.

Task 7

Critically evaluate your proposal and prepared by you for task 5 and 6. Prepare a report of critical evaluation mentioning relevant aspects with improvement.

Task 8

Be ready for a presentation with your teacher to demonstrate your knowledge with concepts incorporated on the assignment.

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

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;

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.

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

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]