Software Analysis And Design

Published Date: 02 Nov 2017

MODULE 2 ASSIGNMENT

K. B. ALAWATHUGODA

HND/C/56/27

ACKNOWLEDGEMENT

This assignment has been completed with the great help from my teacher Mrs. Ruvanthi Perera and immense backing up support from my family.

EXECUTIVE SUMMARY

This report contains detailed descriptions on the Software Development life Cycle (SDLC). Applying it to a practical situation of designing a software to ‘buy and sell vehicles online’. Detailed diagrams and descriptions are included in the report.

TABLE OF CONTENTS

TASK 1........................................................................................................pages 05- 10

1.1 INTRODUCTION.........................................................................................page 05

1.2 STAGES OF SDLC.......................................................................................page 05

1.2.1 Feasibility Study & Requirement Gathering......................page 05

1.2.2 Design.................................................................................page 08

1.2.3 Coding.................................................................................page 09

1.2.4 Testing................................................................................page 10

1.2.5 Maintenance........................................................................page 10

1.3 IMPORTANCE OF SDLC............................................................................page 10

TASK 2........................................................................................................pages 11- 13

TASK 3........................................................................................................pages 14- 21

TASK 4........................................................................................................pages 22- 23

4.1 The Triple Constrains of a Project.................................................................page 22

4.1.1 Time Feasibility..........................................................................................page 22

4.1.2 Cost Feasibility...........................................................................................page 22

4.1.3 Scope Feasibility.........................................................................................page 23

TASK 5........................................................................................................pages 24- 30

TASK 6........................................................................................................pages 31- 34

TASK 7........................................................................................................pages 35- 36

TASK 8................................................................................................................page 37

TABLE OF FIGURES

Fig 1.1..................................................................................................................page 10

Fig 2.1..................................................................................................................page 11

Fig 2.2..................................................................................................................page 12

Fig 2.3..................................................................................................................page 12

Fig 3.1..................................................................................................................page 17

Fig 6.1..................................................................................................................page 31

Fig 6.2..................................................................................................................page 32

Fig 6.3..................................................................................................................page 33

Fig 6.4..................................................................................................................page 34

LIST OF TABLES

Table 1.1..............................................................................................................page 09

Table 3.1..............................................................................................................page 18

Table 7.1..............................................................................................................page 36

TASK 1: Explain the stages of the software development life cycle and explain the benefits and drawbacks of the staged life cycle model for the proposed system.

1.1 Introduction

Software Development Life Cycle or SDLC is a step-by-step process which is used to investigate, analyse, and provide software solutions to a particular requirement. SDLC consists of mainly five stages, they are;

Feasibility Study & Requirement Gathering

Design

Coding

Testing &

Maintenance

1.2 Stages of SDLC

1.2.1. Feasibility Study & Requirement Gathering

> Feasibility Study

Feasibilities are of three main sections namely: 1. Cost

2. Time

3. Scope.

These sections are collectively called as the "Triple Constrains" of a project.

Cost Feasibility

Cost feasibility is analysing the budget to complete a given project. In a project there are initial costs as well as additional costs that are incurred while the project is attended. The project analysts have to analyse and provide a suitable budget where requirements are met and the investment is as much as possibly minimised.

Scope Feasibility

Scope feasibility is very important for it gives the green light or else the red light for a project. The analysts have to analyse the feasibility of a project and whether the desired objectives are achievable. Also the possibilities to fulfil the customer’s requirements are examined. Therefore a project can only succeed if the scope feasibility is positive.

Time Feasibility

In time feasibility, the required time period to complete a project is analysed. The possibility of accomplishing the tasks within a given period of time is analysed in time feasibility. Time feasibility is very important in a software development project for most of the projects are run out of time due to failed time feasibility studies.

> Requirement Gathering

Even though in the beginning the customer provides the software development team with an overview of the requirements, the team will go further into the requirements of the customer in a systematic way. There are several ways of requirement gathering. These ways can assure that the correct and specific requirements are identified during the study. Five main ways of requirement gathering are;

Observations

Interviews

Questioners

Researches &

Website visits

1. Observations

Observing a current system before an automation of the existing system; helps the SDLC process to identify what and where improvements can be done. Usually when a new system replaces an existing one, the workers find some components or functionalities difficult to use. By observing an existing system, analysts along with developers can have a better understanding on how a new system should be designed so that the users of the new system will have minimal difficulties in using it.

Observations are carried out without disturbing usual routines where a current system is active and running. However, sometimes during observations normal routines can be disturbed due to overreacting of the workers. Therefore the analysts have to strive in not disturbing usual routines. Observations are cheap and most of the times accurate in what they reveal.

2. Interviews

Two types of interviews unstructured & structured are conducted during requirement gathering to mainly reveal specific information from workers. Structured interviews have all specific questions where unstructured interviews have a few of the specific questions. The questions raised during an interview session can provide required information to the analyst. An interview however, can sometimes provide the requirements gathering process with insufficient information due to the overreactions and stresses incurred by the interviewees. Yet the analysts can be innovative in making an interview session a user-friendly one so that correct information can be gathered.

3. Questionnaires

As in interviews questionnaires are made to gather specific requirements in order to design a new system. There are two formats of questionnaires as free-format questionnaires and fixed format questionnaires. Free format questions expect the participants to answer questions with their own views on issues, where fixed format questions will have specific answers to clearly identify issues and requirements which are needed by the software development team.

4. Researches

Researches can be carried out to gather extra information on requirements, but can be time consuming. Researches can reveal information which cannot be gathered by other forms of requirement gathering methods. In researches comparisons are made, therefore a broader view on a problem can be seen; which will pave way for a better software design.

5. Website Visits

Existing automated systems which are similar to the required system can be studied to get an idea on how the new system should be made. Even though website visits can directly provide the designers with new ideas, the designers have to think in new perspectives, and be creative to design a new system; which is competitive with the ones visited for research without imitating and creating replicas!

When feasibility study & Requirement Gathering is completed on all the required fields, two formal reports called "Feasibility Study Report" and "Software Requirements Specification Report" (or "SRS report") are made pointing out the feasibilities and requirements of the system, so that the designers can understand how the software has to be shaped.

1.2.2. Design

After the requirements are gathered, the proposed system has to be designed. The design of a system is like the blue print of the solution of a software development project. Designing is done in a systematic way using several standardised languages & methodologies. There are several ways of designing a system. A few of them are:

1. Entity Relationship Diagrams (ER Diagrams)

2. Data Flow Diagrams (DFD)

3. Flow Charts

4. Structure Charts

5. Unified Modelling Language (UML) Diagrams

6. Decision tree & decision tables

Out of the above mentioned modelling techniques, ER diagrams, DFDs & UML are tree standard systematic modelling techniques.

ER Diagrams- These are a logical representations of data of an organisation, arranged in such a way that it is easy to be understood to "code" the software.

DFDs- These show the movement of data in a system and where data is stored.

UML- This is a design language which uses special symbols to denote the way the system is handled.

When designing is complete, a document is made called the "design document" which includes these information;

specified principle data structures

functions, algorithms, heuristics, or special techniques used for processing

the basic program organisation should be stated specifying subdivisions, modularisation, internal & external interfaces

project specific information

1.2.3. Coding

After the project design has completed, coding or construction phase can start. If the requirements and designing are done carefully, coding is a matter of interpreting what the design and requirements consist; using special languages used to develop software. Such languages are:

JAVA

C++

C#

Before coding it has to be ensured that the coding consists of the design. Code and design should have the same modular structure and the same module interface. Rectifying coding errors during the coding phase itself can reduce the unnecessary time consumption in the testing phase.

A document called the "coding document" is made after completing the basic coding. This includes the coding procedures and techniques such that future alterations in coding, if any, can be done by reference to the document.

1.2.4. Testing

When the coding too is complete or literary when the software is done, it has to be tested to ensure its functionality. In testing several principles are concerned, like;

Be systematic in the approach to testing

Test partially, then aggregate

Save, organise and annotate test runs

Concentrate testing on modules which exhibit more errors

Retest when modifications are made

There are two testing techniques that are used during the testing phase. They are Black Box tests and White Box tests.

Table 1.1- Different types of testing techniques

Black Box Tests

White Box Tests

Boundary value analysis

Statement coverage

Equivalence partitioning

Decision coverage

Cause effect graphing

Condition coverage

Error guessing

Decision/Condition coverage

Multiple condition coverage

Here black box tests are carried out by the Quality Assurance engineer, and expert knowledge is not needed. White box tests are carried out by the programmer who must have expert programming knowledge.

1.2.5. Maintenance

Maintenance is the longest phase in SDLC for as long as the software is utilised, it has to be maintained. After the initial four stages in the SDLC are completed a special document called the "User Manual" has to be prepared. It is in this document that all the instructions for future maintenance are included. Usually when software is made and implemented, the rest of the work regarding the software is done by its users. Therefore the software development team has to provide the users of the software with instructions for use, maintain, and troubleshoot the software after it is implemented.

1.3. Importance of SDLC

SDLC is important in the process of creating software for a particular purpose. Since SDLC is systematic it creates a step-by-step procedure in approaching the implementation of ‘better software’. Even though software can be made in a much easier way, such concern is given to this procedure is because when you stick to such a mannered process, it will minimise errors and shortcomings in the final product, for every simple detail is attended during the SDLC.

I have selected the "Prototyping model" to construct the required software for the relevant company. It has several advantages that no other model has like;

Project can begin without a complete idea on the requirements

Risk is spread-out over multiple software builds

Operational capability is achieved earlier in the program

Newer technology can be used as the desire of the customer

Customer interaction is considerably greater, and can get more customer feedback.C:\Users\Ale\Desktop\images for SAD assignment\prototype_model.jpg

Fig. 1.1 – Prototyping Model

TASK 2: How does the spiral model overcome the limitations of the Waterfall cycle model and the Incremental model? Explain by referring to the proposed system.

The Waterfall Cycle Model

Disadvantages:

Risk is high, because acceptance test can fail.

The working product is not available until the end of the project

Progress & success are not observable

Corrections must often wait the maintenance phase

Customer interaction is low

Feasibility Study & Requirement Gathering

Fig. 2.1- The Waterfall Cycle Model

Maintenance

Testing

Coding

Design

Incremental Model

C:\Users\Ale\Desktop\images for SAD assignment\waterfall_model.pngC:\Users\Ale\Desktop\images for SAD assignment\waterfall_model.pngC:\Users\Ale\Desktop\images for SAD assignment\waterfall_model.png

Fig. 2.2- Incremental Model

Disadvantages:

The majority of requirements must be known in the beginning

Cost and schedule overruns may result in an unfinished system

Formal reviews may be more difficult to implement on incremental releases

Spiral Model

C:\Users\Ale\Desktop\images for SAD assignment\Spiral_model_(Boehm,_1988).svg.png

Fig. 2.3- Spiral Model

Advantages over the other two models:

Provides better risk management than the other models

Requirements are better defined

System is more responsive to user needs

Customer feedback can be more effective

However the selected model to be used in the project that is concerned is the prototyping model, because prototyping model is cheaper than the spiral model. And if the clients are not willing to finance more on the project, the prototyping, model is the best available.

TASK 3: Prepare a "Feasibility Report" to the proposed system and discus its components. The report should consist of introduction, purpose of the feasibility report, project description, system functionality, feasibility study (time, cost, scope, technical, economic) conclusion and referencing.

FEASIBILITY REPORT FOR UNIMO CAR SALES (PVT.), LTD.

BY KBA

FEASIBILITY REPORT-TABLE OF CONTENTS

INTRODUCTION.....................................................................................page 15

PURPOSE OF THE FEASIBILITY REPORT.........................................page 15

PROJECT DESCRIPTION.......................................................................page 15

SYSTEM FUNCTIONALITY..................................................................page 15

FEASIBILITY STUDY............................................................................page 15

TIME FEASIBILITY....................................................................page 16

COST FEASIBILITY....................................................................page 17

SCOPE FEASIBILITY..................................................................page 18

TECHNICAL FEASIBILITY.......................................................page 19

ECONOMICAL FEASIBILITY.....................................................page 19

CONCLUTION.........................................................................................page 20

REFERENCING.......................................................................................page 20

3.1 INTRODUCTION

This report contains the detailed description of the Feasibility Study conducted according to the requirements of the clients, gathered. Feasibility study was conducted over a substantial time period to understand the strengths and weaknesses of the current system and to understand the possibilities of introducing the new system into the clients’ workplace.

3.2 PURPOSE OF THE FEASIBILITY REPORT

This Feasibility Report will provide the detailed description of the possibilities and the impossibilities of the firm to develop the current system into the expected automated website. Further, this report includes the Feasibility Study details.

3.3 PROJECT DESCRIPTION

This project is intended to unfold to design a new automated system for the clients to carry out trade transactions online through the expected outcome of the project, ‘a fully functional, innovative, and modern website for vehicle & all vehicle-related sales’.

3.4 SYSTEM FUNCTIONALITY

The website will function as a fully loaded web space for its users. It will provide car listing facility to the sellers, which will list out the results for the buyers. The users can also create and maintain an account for themselves, whether the user is a buyer or a seller, making trading more interactive and social. The backend of the system will be a user-friendly interface, with simplified maintainability. The website management will be able to manage the website with minimum effort; using newer software and hardware. Hence the system will be a better system for the required purpose.

3.5 FEASIBILITY STUDY

The feasibility study revealed that initially the project requires approximately (according to the assessed information), one (1) year for the completion of the required phases. There was in depth analysis on all fields of the firm to gather the requirements of the study. Detailed description is provided below.

-TIME FEASIBILITY

The time requirement for the project is calculated after studying the initial requirements. However the time required can increase as the developments take place while the project is already started. The time feasibility initially recognised is shown in the graph below.

Fig. 3.1- Estimated time consumption in days

PHASE

DURATION IN DAYS

Feasibility Study

48

Requirement Gathering

46

Design

75

Code

58

Testing

63

Implementation

15

TOTAL NUMBER OF DAYS

305

Table 3.1- Summary of the DurationSUMMARY OF THE DURATIONS

-COST FEASIBILITY

There was a detailed study conducted to assess the initial coasting of the project. However the cost on the ongoing project can change at any time due to various requirements like price increases in the market, salary reforms, tax alterations, project requirement adjustments & added features, etc. The study revealed the following information.

INITIAL COSTING OF THE PROJECT

Table 3.2- Initial Costing of the Project

Cost for Project Managers

Rs. 62,000

Cost for Project Analysts

Rs. 88,375

QA Engineers

Rs. 42,300

Cost for Developers

Rs. 68,000

Business analyst

Rs. 30,000

Hardware cost

Rs. 146,500

Software Costs (inclusive of licensing)

Rs. 84,000

Cost for other Human Resources

Rs. 108,000

Facility Costs

Rs. 90,000

Electricity Cost (estimated)

Rs.80,000

Water Cost (estimated)

Rs. 38,000

ESTIMATED TOTAL (exclusive of VAT)

Rs. 837,175

ESTIMATED TOTAL (inclusive of VAT- 8.5 %)

Rs. 908,334.88

-SCOPE FEASIBILITY

Since the clients have a broader requirement regarding the website, scope too is broader. The clients specifically mentioned several requirements; buy and sell vehicles, provide cyber space for automobile-related advertisements, make the website interactive for trading, are few such requirements.

An overview of the scope is as follows;

The firm is fully supporting the project and they are willing to go on with the developments made by the new project.

The firm’s management wishes to train the employees with the required skills to operate the new system; hence the software team is given the opportunity to make advanced developments regarding the operational scope of the proposed system. Further the clients do not wish to reduce the current number of employees.

The website is thought to improve the company’s image because of the implementation of technology into their trading.

Ethical issues are not a major concern; however there are several concerns of the clients to make the website a safer cyber space by introducing few policies for its users.

Legal background is to be established by professionals before the implementation of the new system.

-TECHNICAL FEASIBILITY

Technical feasibility refers to the hardware & software resources that are related with the new system. In this particular feasibility the possibility of developing the hardware & software resources are assed, and the effects of such developments are too examined. The below concerns were looked in this feasibility study;

Whether the recommended software and hardware provide the expected performance, and accomplish the required tasks?

Does the firm require expert technical knowledge to manipulate the new system?

The reliability of the new proposed system, and will the proposed system is able to handle greater workloads in the future?

Assessing whether the firm’s requirements are matching with the proposed system specifications?

-ECONOMICAL FEASIBILITY

Economic feasibility means that the expected benefits of the system outweigh the estimated costs, which is considered as the Total Cost of Ownership (or TCO). As mentioned before in cost feasibility section, the assessed capital of the project is the report for the main expenses, and further studies on feasibility have proved that the TCO can be outweighed as the new system progresses.

Since the firm does not wish to make any new changes to the current system yet, such as reduction of the current labour, job cuts, salary reformations etc., there is no need to conduct another economical assessment to understand the costs and profits of the new system. However we as the Software Development Team recommend your firm to conduct a relevant assessment on costs and profits by a certified professional so that required aims can be set later.

3.6 CONCLUTION

To conclude the Feasibility Report for the new system, it is identified that the newly proposed system for an automated system to conduct trade online is ‘a feasible project’ which is ‘profitable for the investors’. We as the analysts of the Software Development Team recommend your firm that this project is worth starting and that your support will lead to a fruitful new system.

3.7 REFERENCING

Rosenblatt, S. C., unknown. Systems Analysis and Design. Sixth Edition. Thompson.

TASK 4: Assess the impact of Time, Cost, and Scope feasibility criteria on systems investigation for the recommended solution.

4.1 The Triple Constrains of a project

4.1.1 Time Feasibility

Time feasibility means the possibility of finishing a project on a planned time frame. While a project is ongoing new developments on a proposed system can be included which will affect the time frame. Also, unexpected time outruns can too be incurred. Therefore an assessment on how much time is needed initially, keeping allowances on unexpected time consumptions, has to be provided for the software development team as well as the customers who expect the new system. This is done by the systems analyst. Time feasibility is a very important aspect in a software development project, because assessing the time to achieve the required outcomes at the beginning will draw a sketch on the estimated completion of a project.

4.1.2 Cost Feasibility

Cost feasibility means that the project will generate profits outweighing the cost for the development process or the total cost of ownership (TCO). The cost for a project includes ongoing expenses and acquisition costs. To calculate the TCO analyst have to look into the following areas;

People, including IT staff and users

Hardware & equipment

Software, including in-house development as well as purchases

Formal, and informal training

Licenses and fees for special software

Consulting expenses

Facility costs

Estimated cost for postponing of an undeveloped system

Apart from these Tangible and Intangible benefits too have to be looked into. Tangible benefits cannot be measured in currency but can improve the productivity of a company (e.g. mental satisfaction due to a user-friendly system).

4.1.3 Scope Feasibility

Scope feasibility is the ability of the system to do the required tasks. For example,

Whether the new system is capable of improving productivity or will it reduce productivity?

Will training be required by the users of the new system?

Will the new system have adverse effects on its users either temporarily or permanently?

Therefore it is necessary to assess the abilities of the system at the beginning, before starting a project. The analysts must analyse whether a new system could cater the needs of the customers. And provide a better productivity.

TASK 5: Investigate the system requirements and prepare a sample SRS for the proposed system. The document should consist of Introduction, Purpose, Scope, Definitions, Overall Descriptions, Hardware, Software, Functional & Non-functional Requirements, Conclusion and Referencing.

SOFTWARE REQUIREMENTS SPECIFICATION (SRS) REPORT FOR UNIMO CAR SALES (PVT), LTD.

BY KBA

SRS-TABLE OF CONTENTS

5.1 INTRODUCTION...............................................................................page 25

5.2 PURPOSE...........................................................................................page 25

5.3 SCOPE................................................................................................page 25

DEFINITIONS......................................................................................page 26

5.4 OVERALL DESCRIPTION...............................................................page 26

5.5 HARDWARE REQUIREMETS.........................................................page 26

5.6 SOFTWARE REQUIREMETS..........................................................page 26

CUSTOMER ROLE..............................................................................page 26

ADMIN ROLE......................................................................................page 27

5.7 SPECIIFIC REQUIREMENT.............................................................page 27

5.8 FUNCTIONAL REQUIREMENT......................................................page 27

5.9 NON-FUNCTIONAL REQUIREMENT............................................page 28

5.10 CONCLUTION.................................................................................page 29

5.11 REFERENCING...............................................................................page 29

5.1 INTRODUCTION

UNIMO CAR SALES (PVT) LTD. is a private car sale founded in 2001 and has been a leading business firm in the industry. The management wishes to improve productivity of their firm and make more customers to do business with their firm. To reach the improvement goals of the company the management has aimed in automating the sale by allowing online vehicle trading, where customers can login remotely and the relevant persons from the car sale to assist them on the other side of the wire. This document illustrates the relevant software requirements of a proposed system laid out according to the feasibilities gathered.

5.2 PURPOSE

The purpose of this website is to buy and sell vehicles online. The management has a main aim of providing publicity o their website and make online vehicle trading popular in the country. The website is to be used as a marketing tool, allowing the website’s cyberspace for advertising on related fields (i.e. automobiles). The website is to be made fairly safe on legal terms as well as socially for the users; transactions to be monitored under legal supervision, and customer privacy to be maintained at a favourable standard. Since online trading is a growing field in the country, the website must be a user-friendly tool for trading, on both customer and manager wise. The website has to be flexible enough to cater the customer needs as well as the management requirements. Future developments, integrations and, maintenance of the website are a major concern in terms of increasing the site’s popularity among the people.

5.3 SCOPE

The customer has the ability to customize his trade by comparing prices & features with different items, use the privileges provided by the website to ease the trading difficulties like; legal assistance, leasing schemes & other payment methods, step-by-step trading assistance, 24/7 help desk, maintain contacts with the buyer/seller, obtain notifications through e-mails & SMSs or phone calls.

The site management has to be trained briefly with regard to operations in the website management. The website’s maintenance has to simplified so that maintenance difficulties are reduced allowing more productivity on the website’s operational side.

DEFINITIONS

SRS-Software Requirements Specification

SMS-Short Message Send

5.4 OVERALL DESCRIPTION

As requested by the ownership of ABC CAR SALES (PVT) LTD. a website to automate the vehicle trading activities of the firm is designed to suit the needs. The website will cater the customers with a broader scope of vehicle trading and the management of the website to manage it with least possible effort making less space for operational errors and increased productivity. The website will always have aims to develop and integrate the site into a better outlook and functionality.

5.5 HARDWARE REQUIREMETS

Since there is a lot of weight on the website as a whole (i.e. a lot of areas of functionality, a lot of options) there has to be super performance hardware to aid the website’s function. Therefore the following hardware can be recommended:

5.6 SOFTWARE REQUIREMETS

Up-to-date software with latest technology providing an optimum platform for the website designing and maintenance must be used in order to make the website fresh and innovative. Hence the following software are recommended:

CUSTOMER ROLE

Use the website to search for vehicles & other related items posted in the site and do relevant transactions using the facilities provided in by the website. Customers are bound to accept and stay within the policies of the website management for the sake of both customers and the management. Customers can provide feedback regarding their website experience and complaints too are allowed to be forwarded to the website management.

ADMIN ROLE

Administrators are to constantly monitor the website’s functionality and make relevant amendments to improve functionality. The website administrator/s is/ are responsible to all the changes made and decisions taken. Administration has the sole right to the website’s policies both legal and user (privacy). Administration will look into user problems if any.

5.7 SPECIFIC REQUIREMENT

This system is intended to produce a website where vehicles can be bought and sold and all other requirements concerning automobile can be met, i.e. vehicle parts sales, integration techniques, insurance policies, leasing schemes, etc. User-friendliness has to be a main priority of the website; allowing users to have a better experience in online vehicle trading. The users are given the privilege of leaving feedback, asking questions, obtaining legal assistance with regard to trading activities, and many more options on customised online vehicle trading.

The website has to be eligible for future developments, on customer feedback and due to technological developments. The website must be an easy-to-manage one with a simpler interface so that greater expertise & knowledge is not required by the staff in the management; allowing improved productivity of the newly introduced automated system.

5.8 FUNCTIONAL REQUIREMENT

The front end of the website is a user friendly interface where vehicle information is displayed, and items can also be displayed on demand. The user can make their own accounts to maintain a record of their activities on the website (however it is necessary to be a registered user to engage in trading activities). The website will function as an advertising tool, which advertises relevant information with regard to the content on the website, and at cases with regard to the usage of a registered user (i.e. displaying of advertisements on personal accounts relevant to the key words the users frequently use, and their personal interest on items they search in the website – "targeted advertising")

The back end of the website will be as much as possibly simplified, so that operations are easier to be carried out. The website management will have the sole authority; on allowing transactions to take place, posting of advertisements, allowing modifications, providing users with relevant information, filtering information included in the website, making of privacy & social policies that ensures the richer online trading experience to the website’s users.

5.9 NON-FUNCTIONAL REQUIREMENT

>Security

The security of the website has to be optimised such that user accounts are safe from 'hackers & crackers’, allowing maximum privacy on private content on the website. On the operational backgrounds, authorities on website’s major changes are given to the senior website management, where special administrator clearance is required (e.g. higher bit encryptions, facial recognitions, finger print recognitions, etc.)

>Reliability

Reliability on information on the website is assured by the use of world renowned hardware & software at the most optimum price. Safer methodologies on data handling like procedural data updating & removal (e.g. providing recycling storages for removing information in case necessary information gets deleted accidently) are to be used in the website management techniques.

>Maintainability

Since the website is designed to be simple on the user’s perspective as well as the management’s perspective, maintainability is expected to be a minimum-hassle process. Software maintainability is also made simple by making the design as simple as possible making it less confusing. The utility & application software used are allowed to update to latest builds so that the newest software are used and therefore better maintainability can be obtained.

5.10 CONCLUTION

This is a website which is to be used for online vehicle trading purposes, where buying & selling of vehicles can be done. There can be user accounts made & maintained in the website. The website is made as much as possibly simpler in its interface and maintainability; in both front and back ends. The website is allowed to be developed in the future, allowing newer technology and ideas to reshape the structure, functionality, and purpose of the website.

5.11 REFERENCING

Rosenblatt, S. C., unknown. Systems Analysis and Design. Sixth Edition. Thompson.

TASK 6: Draw the Context Diagram, Level 0 DFD, Level 1 DFD, and ER Diagram, for the proposed system.

The Context Diagram

WEBSITE MANAGEMENT

BUYER

SEARCH FOR A VEHICLE THROUGH MODEL

SELLER

RECEIVE INFO. ON ALL POSSIBLE MATCHES

REQUEST FOR LISTING A VEHICLE

UPDATE NEW COMMISION PRICES

UPDATE NEW LISTING PROCEDURE

GET DETAILS ON LISTING

REQ. NEW USER LIST

REQ. MONTHLY REPORT

GET NEW USER LIST

0

Online Vehicle Trading System

GET NEW USER LIST

REQ. NEW USER LIST

GET MONTHLY REPORT

RECEIVE PAYMENT DETAILS

POST ADVERTISEMENT

GET ADVERTISEMENT DETAILS

REQUEST FOR NEW ADVERTISING SLOTS

UPDATE NEW ADVERTISING SLOTS

WEBSITE MANAGEMENT

UPDATE MONTHLY REPORT

WEBSITE OWNER

ADVERTISERS

Fig. 6.1- Context Diagram

UPDATE NEW LISTING PROCEDURE

1

LISTING PROCESSLevel 0 DFD

RECEIVE REG. FORM

BUYER

REQ. TO REGISTER

GET NEW USER LIST

REQ. NEW USER LIST

UPDATE NEW COMMISION PRICES

WEBSITE MANAGEMENT

SELLER

2

USER REGISTRATION PROCESS

3

SEARCHING PROCESS

4

ADVERTISEMENT MANAGEMENT PROCESS

TRANSFER DATA

SEARCH FOR A VEHICLE THROUGH MODEL

RECEIVE INFO. ON ALL POSSIBLE MATCHES

REQ. TO REGISTER

RECEIVE REG. FORM

TRANSFER DATA

GET DETAILS ON LISTING

REQUEST FOR LISTING A VEHICLE

REQUEST FOR NEW ADVERTISING SLOTS

GET ADVERTISEMENT DETAILS

ADVERTISERS

RECEIVE PAYMENT DETAILS

POST ADVERTISEMENT

WEBSITE OWNER

5

REPORT GENERATION PROCESS

Fig. 6.2- Level 0 DFD

TASK 7: Include the system analysis information into a document. This document should consist of the background of the problem and problem statement, the process which will be used to collect required data and recommendations suggested for addressing the problem and any other relevant information.

QUESTIONNAIRE

Unstructured

1. Do you feel any requirement to go into a new, automated system?

___________________________________________________________________________

2. Is there a considerable increase in business in your firm? If so why?

_____________________________________________________________________

3. What benefits will you think a new automated system will provide to your firm?

_____________________________________________________________________

4. What specialities will you expect in a new automated system?

_____________________________________________________________________

5. How comfortable will you feel with a new automated system, will it be difficult for you to use it or not? Please explain.

_____________________________________________________________________

6. Do you think it is worth to spend on an automation of an existing system? Explain.

_____________________________________________________________________

7. According to you, will there be an increase in the business of the firm by automation? Please explain.

_____________________________________________________________________

8. Do you see any inappropriateness of an automated system for your firm? Please explain

_____________________________________________________________________

9. If an automated system will be helpful to you in any way, or ways; what will they be? Please explain your reason.

_____________________________________________________________________

10. Are you looking at a new automation of your firm’s business, positively or negatively? Please explain briefly, your reasons.

Structured

1. Do you like an automated system to be used to do manually carry out business?

YES NO

2. Do you feel confident in working with an automated system?

YES NO

3. Do you think an automated system will save your work time?

YES NO

4. Would you like to customise your job in order to make work easier?

YES NO

5. Do you like to work with the newer technology?

YES NO

6. After a new system is implemented, do you think it has to be updated with the latest technology?

YES NO

7. Will you like to work with an automated system?

YES NO

Summary of the Structured Qs:

There were fifteen (15) people who took part in answering the questionnaire. The summary of their answers are shown below, for the structured questions.

Table 7.1- Summary of the Structured Qs

Question Number

YES

NO

Q1

11 - 73.33 %

4 - 26.66 %

Q2

13 – 86.66 %

2 – 13.33 %

Q3

14 – 93.33 %

1 – 6.66 %

Q4

9 – 60 %

6 – 40%

Q5

8 – 53.33 %

7 – 46.66 %

Q6

10 – 66.66 %

5 – 33.33 %

Q7

11 – 73.33 %

4 – 26.66 %

TASK 8: Prepare a questionnaire that can be used to gather requirements of the proposed system and identify the user requirements. Evaluate the usefulness/ suitability of the questionnaire which you have prepared for requirement gathering process.

Unstructured

Q1- even though the heads of the company are keen in automating their business it is required to know what the employees think of regarding an automation in the current manual system.

Q2- since developing a new system is costly, as a software development team, we must know the background of our clients, i.e. whether they are in a state to fund such a project.

Q3- the ideas of the employees as well as the management of a firm regarding the benefits they think of an automated system have to be analysed for their requirements are indirectly expressed in an answer to such a question.

Q4- this question directly asks the employees & management of the firm about the special requirements they need in a new system

Q5- the ICT literacy is examined in this question. It is very important to assess whether the expected users of a new system are capable to use a newly implemented system. If not training has to be delivered.

Q6- to know the view of especially the management, regarding the expected outcome of a new project, is the idea of this question.

Q7- the positivity of the employees as well the top level management of the firm regarding the new system is assessed in this question.

Q8- if any of the employees have a negative idea regarding the newly proposed system, it is extremely necessary to know it and the reasons for it. This question is made for that purpose.

Q9- the expectations of a new automated system is examined in this question. Since it is unstructured, the employees can answer it freely, therefore it will let the software development team identify the vivid thought of the employees on a new system.

Q10- a final touch-up question to finish off the questionnaire. This question is rather direct. However studying the explanation of the answers will help the analysts understand where the future users of an automated system stand. Therefore designing the new system can be done accordingly.

Structured

Q1- to specifically understand the likes & dislikes for an new system

Q2- to assess the ICT literacy of the future users

Q3- the time-consciousness is assessed

Q4- to know if the employees require a user-friendly interface

Q5- the likeness & dislikes on new technology is assessed

Q6- the requirement of staying up-to-date is assessed

Q7- finally, the need to work with an automated system is assessed