Thomaset2000’s Room

Hi! Meet again in the second part of C2002 Software Engineering module term 2 2008 assignment post.

In this post I will write the answer of the assignment’s question that I posted in the previous post. Basically, the scenario question of this assignment is about development of a CFMS (Cash Flow Management System). The specification of the system is given in the scenario.  We take role as a freelance software consultant that help to make decisions on the development of this system.

The first question (a) ask about what software life cycle that we will use, the second question ask about how to ensure the dependability of the system, and the last question (c) ask about the risks that may happen during the development of this system. You can read the full scenario and the questions in the previous post, or you can click here.

Now, the answer is as follows:

Answer for question A

After looking and examining the scenario of the CFMS software. I would choose the combination of classic SDLC (System Development Life Cycle), Prototyping, and 4GL (4th Generation Language) to be applied in the development of the CFMS software. So, this method is like using the classic SDLC method but we combine it with prototyping that is generated using 4GL after the requirement gathering or the initial study phase.

Below is a diagram that shows the overall stages of this method:

As we can see from the diagram, the overall process is very similar with normal classic SDLC. The only difference is that after the requirement gathering stage of the classic SDLC, there is a Prototyping stage that uses 4GL to generate the prototype.

In general, each software life cycle model has its own strengths and weaknesses. I will try to identify the strengths and weaknesses for each classic SDLC and Prototyping here as these two methods will be used in developing the CFMS (Cash Flow Management System) Software.

Classic SDLC (System Development Life Cycle):

a. Strengths

1.      A project that is carried out with classic SDLC will have clear objectives and prevents that the project moves away from the main objective.

2.      Classic SDLC project is stable and easy to review as we can have checkpoints during the project progress at the each stage of classic SDLC. Thus leads to a better system quality.

3.      We can easily measure the progress of a project that is carried out using Classic SDLC system.

4.      A system developed using classic SDLC will have many documentations since classic SDLC produce a documentation in each stage. These documentations are useful for future development or modification to the system.

b. Weaknesses

1.      Classic SDLC takes a quite long time to deliver a finished and fully working system.

2.      If there is a lack of requirement or specification that is unrevealed during the early stages, the project will have a difficulty to accept the changes as it has to go back and repeat many stages.

Prototyping

a. Strengths

1.      Prototyping ensures a good communication between the user and the development team.

2.      The use of prototyping method in a system development project will minimize the risk of missing system specification as the team have a good communication with the user.

b. Weaknesses

1.      It is difficult to monitor the project’s progress and implement a strict working standard. This will lead to a poor quality product.

2.      There is inadequate documentation when we use a pure prototyping method to develop a system. This will make evaluation and further development of the system become harder.

III.a. Reason to use combined Classic SDLC & Prototyping for CFMS Software:

After examining the strengths and weaknesses of Classic SDLC and prototyping, I see that the best option to develop the CFMS (Cash Flow Management System) Software is to combine these two software life cycle model (Classic SDLC and Prototyping), because we can take the strengths from both classic SDLC and Prototyping to be an advantages in developing this CFMS Software.

The factors that support my decision to apply combined SDLC and Prototyping in this CFMS Software development case are:

1. We can use the strengths from both classic SDLC and Prototyping.

1. CFMS Software is business software that will play an important role in the   trading company, it should require minimum maintenance and reliable enough to run flawlessly, so we need the best quality software possible. In this factor, Classic SDLC is favourable as it can deliver good quality software.

1. As stated in the scenario, the CFMS software is expected to run on some different network operating system such as NetWare, Windows NT, etc. This means that it will need a thorough study about some network operating system where the CFMS software is expected to run. So, this factor supports the use of classic SDLC that do more requirement gathering and analysis to make sure that the CFMS software have reliable performance when it is used on some different network operating systems.

1. It is stated in the scenario that the CFMS Software is a software package that must be able to handle the company’s accounts, payment, and income. For the payment itself, there are so many different fixed and variable amounts of payment. The same thing also applies for the company income and accounts. Because each company is not exactly using the same types of accounts, payments, and income, so I suggest that we need to make the CFMS software more personalized to each company’s characteristics. In this factor, the use of prototyping will be very helpful as the development team can works closely with the user from the company to gather specifications specific to the company and make the CFMS software more personalized for the company to manage the cash flow.

1. The last paragraph of the scenario states that the CFMS Software must be able to generate report data to be used as analysis material by the accountants. The prototyping method will be suitable to cover this factor as the developer team can works closely with the accountant to gather their requirements about the report (e.g. What data should be displayed in a report, how the report should be arranged, etc.).

In conclusion, we can see at the five factors above and see that there are some factors from the scenario that supports the use of classic SDLC, and also there are some factors that will be well covered by using prototyping method. So, I concluded that the use of combined classic SDLC and prototyping is the most suitable software life cycle model that can be applied for this CFMS Software development scenario.

III.b. Explanation for each phase in the selected software life cycle model

In this section, I will explain about each phase in the selected software life cycle model for this CFMS Software, that is combined classic SDLC and prototyping.

There are 9 stages in this software life cycle model, they are:

1.)    Requirement Gathering Stage

2.)    Prototyping Stage

3.)    System Analysis Stage

4.)    Program Design Stage

5.)    Development Stage

6.)    Testing Stage

7.)    Implementation Stage

8.)    Live Running and Maintenance Stage

9.)    Review Stage

Each stage in the CFMS software life cycle model is based on the information collected from the previous stage, and each stage will have a product or result that will be used by the next stage. So, we can say that every stage in this CFMS software life cycle model is related or connected with another stage.

1.) Requirement Gathering Stage

Requirement gathering stage is the first stage of this CFMS software development life cycle. This is the stage where we collect all the necessary information to study the CFMS software’s requirement from the user. This information about the CFMS software’s requirement is essential in order to proceed to the next stages in the life cycle. So, there will be a lot of information gathering activities involved in this stage.

Activities taken to complete this stage are:

1. a.)        Study and determine what is the problem that should solved by the CFMS software for the company.

1. b.)        Find out about what are the features needed in the CFMS software to provide solution for the company’s problem (Software Requirement)

1. c.)        Conduct a feasibility study

1. d.)       Produce the feasibility report to carry on with the next stage

1. a.) Study and determine what is the problem that should solved by the CFMS software for the trading company.

When a company wants to use Cash Flow Management System (CFMS) software to aid the trading company in managing the company’s cash flow, there must be a background problem that pushes the company to demand the use of CFMS software.

In order to develop dependable and effective CFMS software, we have to understand what is really needed by the trading company from the software, or in another words we can say that the CFMS software developer must find out what are the features and benefits expected by the trading company from using the CFMS software. When we already have a good understanding on this issue, there will be a clear direction in developing the CFMS software, thus leads to a CFMS software that really match what a trading company need.

We can study the trading company’s current problem by examining the current system that is used by the trading company to manage their cash flow. From this point, we can find out about what are the problems and limitation of the trading company’s current cash flow management system.

Another way to study about this problem is to have an interview with some key person in the trading company that have a well understanding about the current trading company’s problem in managing their cash flow. An interview with the senior management team from the trading company and some other staffs that have an adequate knowledge about this matter can be a good choice because we can get clearer picture about the trading company’s current problem with their cash flow management.

1. b.) Find out about what are the features needed in the CFMS software to provide solution for the company’s problem (Software Requirement)

After we understand the problem faced by the trading company in managing their cash flow using their current system, now we need to find out about how the CFMS software will be able to solve these problems and give the trading company a new convenient way to manage their cash flow.

It is mentioned in the scenario that the CFMS software is required to manage three things such as the company’s bank accounts, the company’s payments, and also the company’s income. So now we need to find out how the trading company wants the CFMS software to manage these three things, how the company’s staff wants the CFMS software to works is also information that we will find out here.

1. c.) Conduct a feasibility study

At this step, we already know what is the problem faced by the trading company in managing their cash flow using their current system. So we know what is expected from the CFMS software that is to solve this problem. And also we have studied about how the trading company wants the CFMS software to deals with things like managing bank accounts, payments, and income.

Now is the time for us to study about the feasibility of this project. We have to ask questions like “Is it feasible for us to develop a CFMS software that meet’s the requirement and demand from the trading company?” should be asked. So, we will get a clear image about whether this project is feasible or not.

The feasibility study that we do in this step also covers about cost and benefit analysis. We need to study about how much is the cost to develop this CFMS software, and what is the benefits both tangible benefits and intangible benefits that the trading company will get after using this CFMS software to manage the company’s cash flow.

1. d.) Produce the feasibility report to carry on with the next stage

In this step, we use the result of our feasibility study about the CFMS software to produce a feasibility report. The feasibility report will contain information like is it feasible to continue this project, the project cost, benefits, and also the time needed to finish the project. This report will be presented to the company’s management in order to get an approval. Only if the project is approved, then we can continue the development of the CFMS software to the next step of its life cycle.

2.) Prototyping Stage

After the feasibility report has been approved from the previous stage, now we can continue with the prototyping stage. The main purpose of the prototyping stage here is to get a clearer and more detailed requirement for the CFMS software from the user (the trading company). This is necessary to reveal any software requirement or specification that is unrevealed during the requirement gathering stage. The CFMS software prototype itself will be generated using 4GL (4^th Generation Language) in order to cut the prototype development time, because we can generate a program quickly using the 4GL technique, and also since we building a prototype just to find out more requirement from the user so we don’t need the best quality program to be the prototype, that’s why applying 4GL technique to develop this CFMS software prototype is the best and the fastest way.

Activities taken to complete this stage are:

2. a.)        Build the first version of the prototype using 4GL technique

2. b.)        Present the prototype to the user to refine the software requirement

2. c.)        Make Changes to the prototype and re-present it to the user

2. d.)       Produce a report about the refined requirements

2. a.) Build the first version of the prototype using 4GL technique

The very first step in this prototype stage is to build the initial prototype of the CFMS software based on the user’s requirement that have been found from the previous stage, the requirement gathering stage.

The prototype of the CFMS software will represent what will be there in the actual CFMS software that will be developed later on. This prototype has some visible functions like bank accounts management, payments recording, and also income recording but actually these functions is not complete, these functions are just build to show the user what the actual CFMS software will looks like. So, the development of this prototype won’t take a long time to finish. Instead, it will be done quickly with the aid of 4GL technique.

2. b.) Present the prototype to the user to refine the software requirement

After we finish building the first version of the CFMS software’s prototype, now we need to present the prototype to the user. Practically, the user who will try this prototype is a staff or some staffs from the trading company who will use this CFMS software in the future.

This step requires a lot of communication between us as the CFMS software developer and the user from the trading company. We will need to gather the user’s feedback about the prototype when the user tries the CFMS software prototype. One of the advantage from using prototype in refining user’s requirement on CFMS software is that user will have a clearer picture about the software, thus leads to better understanding of the user about how the CFMS software will looks like. User feedback may vary from how the interface of the CFMS software needs to be improved in order to be more user-friendly, or the user may find out that there are more requirements that need to be added to the CFMS software. The user may also describe more about what he/she actually expect the CFMS software to be.

2. c.) Make Changes to the prototype and re-present it to the user

Based on the user’s feedback from the previous step, now we need to make changes to the first version of the CFMS software prototype. We have to refine the software’s requirement until it matches with the user’s exact expectation about the software.

The modified prototype is re-presented to the user to evaluate the prototype again and to find out if there is still any requirement unrevealed. If there is any new finding, we can modify the prototype again and then present it to the user for evaluation again. We may repeat this process in a finite number of iteration until we know that we have gathered enough requirements for the CFMS software.

2. d.) Produce a report about the refined requirements

The result of this prototyping stage is a well refined CFMS software requirement. Now we will produce a report of the refined requirement to be used in the next stage of the CFMS software life cycle, the system analysis stage. The prototype itself will be discarded and won’t be used for further development of the actual CFMS software. This is done to ensure that the CFMS software will have the best quality.

3.) System Analysis Stage

Now we continue the CFMS software development with the system analysis stage. In this stage, we will describe the proposed CFMS software more clearly by doing further investigation on the software’s requirement; design the logical structure of the CFMS software, and also prepare enough information as the foundation that will be used by the next stage, the program design stage.

Activities taken to complete this stage are:

3. a.)        Requirements Modelling

3. b.)        Data and Process Modelling

3. c.)        Transition from analysis stage to design stage

3. a.) Requirements Modelling

In requirements modelling step, we have to describe all the requirements of the CFMS software. The CFMS software requirements cover 5 categories that are the software’s input, process, output, performance, and control. These five categories of the CFMS software requirement must be well described and identified in order for the finished CFMS software to be acceptable by the trading company.

Example of the CFMS software requirement in these 5 categories is:

Ø  Input

The input of the CFMS software covers variable payment and variable income, or report request. For the payment, the CFMS software will accept data about payments for credit card, utilities bill, CPF contributions, etc. For company’s income, the user must  input the information for each income, for example if the income is in form of a cheque the user need to input the cheque number, customer name, the amount, etc.

Ø  Process

The process requirement of the CFMS software may covers things about how to synchronize every payment and income of the trading company with the company’s bank account calculation. How to calculate overdrawn or overdraft account and how to process and manage the balance of each account is included in the process requirement of the CFMS software.

Ø  Output

The output requirement of the CFMS software may include about how the software arrange the information when it produces report about the company’s account balance, how is the interface should be designed so the user can retrieve the needed information conveniently, etc.

Ø  Performance

Performance requirement of the CFMS software covers things like how long the software needs to be active, is it 24 hours or just in office hours, and also the expected processing speed of the software. These things are required as the standard to develop the CFMS software so that it can meets with the performance requirement.

Ø  Control

This requirement deals with the security level of the CFMS software. We have to decide how the information in the CFMS software’s database can be secured from unauthorized access, as the CFMS software keep information about the company’s cash flow that is confidential for each company.

In order to collect enough information about these five categories of requirement, we need to do some investigation that involves various fact finding activities. The fact finding activity can be done using one or more than one fact finding technique. Some possible option of fact finding here are interview with some key staff that understand about the company’s cash flow management system, do a questionnaire to find out more information from the company’s staffs, observe the current system to find out how the trading company manages their cash flow using the current system, etc.

3. b.) Data and Process Modelling

After we have done with the requirement modelling step, now we have to do the data and process modelling for the CFMS software. In this step, we have to create the logical structure of the software. We will use a graphical representation to show how the logical structure of the system. Or in another word we can say that we use graphical representation to show how the CFMS software works logically.

The tools used in this step are DFD (Data Flow Diagram) and Context Diagram to show the logical structure of the CFMS software, and also a Data Dictionary to keep detailed information about each data that will be kept by the CFMS software.

3. c.) Transition from analysis stage to design stage

This is the final step to complete the analysis stage of the CFMS software. The result of the analysis stage is a document called system requirements. We will need to have a presentation to the company’s management regarding this system requirement to seek their approval to continue with the development of the CFMS software. The correctness of the system requirements is important because it have the logical design of the CFMS software that will be the foundation of the program design stage. So if we or the management team thinks that the current system requirements document is not complete enough, we can repeat the analysis stage one more time in order to produce a complete and correct system requirements of the CFMS software.

4.) Program Design Stage

In the program design stage, we will design the physical structure of the CFMS software based on the logical structure design from the system analysis stage. The objective of this design stage is to design the CFMS software to be software that is effective, reliable, and maintainable.

We can say that CFMS software is effective if this software can fulfils all the requirements and expectation from the trading company. For example, the CFMS software must be able to do all the requirements stated in the scenario such as managing bank account, payment, income, balance report, and also produce a spreadsheet report for the accountants.

To make the CFMS software to be reliable software, we must design the software to be able to prevent error from input, process, and output. Since the CFMS software will deal with the company’s cash flow, so it has to be designed as accurate as possible.

The final objective is to make the CFMS software maintainable. As we can see in the scenario, it is stated that there are some fixed amount such as rental fee, income tax, property tax, etc. These amounts are fixed but there is always a possibility that these fixed amount will change maybe due to change in government or the company’s policy. So, when these things happen, the CFMS software must be maintainable to adapt with the changes.

Activities taken to complete this design stage are:

4. a.)        Review the CFMS software system requirement

4. b.)        Design the CFMS software

4. c.)        Present the CFMS software design

4. a.) Review the CFMS software system requirement

The CFMS software requirement contains the logical design of the CFMS software, so we need to review this requirement in order to get a very clear understanding about the logical structure of the CFMS software. With a good understanding about the software’s logical structure, we can start to design the physical structure of the software without getting out of the scope and requirement. This physical structure of the CFMS software will be implemented when we start the development stage of the CFMS software.

4. b.) Design the CFMS software

There are some things that we need to design for the CFMS software, they are:

• Input Process Design
• Input and Output Format Design
• Data Design
• System Architecture Design

ü  User Interface Design

User interface is the part of the software where the user can interact with the CFMS software. Here we have to design a user interface that is user friendly with using graphical user interface (GUI) enhanced with an attractive screen layout and design. We make all the user interface design for the CFMS software in this step; it ranges from the software’s main menu, navigation functions, log-in screen, etc.

ü  Input Process Design

Input process design means that we design how the CFMS software will process the input data and how the data will be inputted to the CFMS software. As we know that in data processing there is a term called Garbage in Garbage out (GIGO), that means if the input data is already have fault, then the output will be a faulty data also. As CFMS software will have to process an important data about a trading company’s cash flow, so we need the software to be able to do input data validation check to minimize data entry error. For example, if the user enters data about cheque payment, the software must be able to verify whether the information about the cheque is correct such as the format of the cheque number.

ü  Input and Output Format Design

We also need to design the input and output format for the CFMS software. Input format includes the data input form. The data input form must be user friendly and effective to reduce the data input time. For example, we put the fixed options like direct debits, giro deduction, and bank transfers in option box, and then we put input for variable amount such as amount to credit card payment, utilities bill, CPF contributions, etc., in a text box.

For the output format design, we need to design the format of the company balance report, the warning for the user regarding account that is overdrawn or overdraft, and the format of the report generated by the CFMS software in spreadsheet format.

ü  Data Design

CFMS software will keep so many kinds of data such as bank account data, transaction data, payment data, and income data. The aim of data design step is to design how the data on the CFMS software is

ü  System Architecture Design

System architecture design about how the CFMS software will fit with the environment that is the operating system. As it is stated in the scenario, the CFMS software will need to run in a Windows based PC and some other network operating system, so we need to design the CFMS software’s architecture in order to comply with this requirement.

4. a.) Present the CFMS software design

After we complete the design of the CFMS software, now we need to make the documentation about the design and make a presentation about the software design to the management team. Once the design is approved, then we can say that the program design stage in the life cycle is completed and now we can bring the CFMS software design to the next stage, the development stage.

5.) Development Stage

Now we can start to write the CFMS software with a chosen programming language. We use the software design from the previous stage as the base in writing the programming codes. The programmers need to keep the programming standards such as modular programming concept to make the CFMS software works effectively.

The development stage will covers two main activities that are file creation and application creation. The final result of this development stage is fully working CFMS software that satisfies its requirement. Beside the actual CFMS software, the development stage also produce documentations like input and output specification, data dictionary, and also the operating guide of the CFMS (Cash Flow Management System) software.

6.) Testing Stage

This is the stage where we will test and debug the CFMS software in order to reveals any bug, defect, or error in the software. The main purpose of software testing is to find the errors in the CFMS software; it is not to prove that the developed CFMS software is working without problem.

The testing strategy that can be applied here is the bottom-up testing strategy which start from unit testing that test every single unit or module of the CFMS software, continued by an integration testing that test about how one module interfaces with another module, and finally a system testing is conducted to test the entire CFMS software.

The software development team is always involved in every stage of the software testing, whenever the test reveals an error then the software development team will have to fix the code to eliminate the error and then the software is re-tested until the error is completely fixed. It is important to note that it is almost impossible to make the CFMS software 100% free of error as it is almost impossible to develop perfect software. So, we will place the target of 95% – 98% error free software.

7.) Implementation Stage

The CFMS software has passed the testing stage, so now this software is ready to be implemented to the trading company.

There are some activities that need to be done in this implementation stage:

7. a.)        Conduct user training session

7. b.)        Perform data conversion

7. c.)        Select and apply a changeover method

7. a.) Conduct user training session

In order to prepare the trading company’s staff to use the new CFMS software, a user training session is essential to familiarize the staff that will use the CFMS software in the future. Before a training session, we can release the software’s documentation so the staffs that follow the training session can have a picture about the CFMS software prior to the user training session.

7. b.) Perform data conversion

The data conversion activity is where we convert the data from the old system or from the current system’s format to the CFMS software’s format. This is necessary to make the CFMS software able to continue the cash flow management system of the company from the data of the previous system.

7. c.) Select and apply a changeover method

There is some changeover methods that we can chose in changing the company’s current system with the CFMS software. But I would like to recommend using the pilot conversion changeover method. This method is safe and will reduce risk if the changeover is fail. The pilot changeover method is done by selecting a company’s branch then apply the whole CFMS software at the selected branch, if the CFMS software runs smoothly, then we can start to change  the cash flow management system of the whole company with the new CFMS software.

8.) Live Running and Maintenance Stage

After the implementation of the CFMS software is complete, and then now we enter the live running and maintenance stage. In this stage, the CFMS software has used for the trading company’s cash flow management system every day. During the daily operation, there can be error or bug that happen because these errors is unrevealed during the testing stage. If such case takes place, then the user (the trading company) may request for support and maintenance to fix the error. And then we as the developer of the CFMS software will provide maintenance service to keep the CFMS software working properly.

9.) Review Stage

Review stage is the last stage of the CFMS software life cycle model. This stage will only take place after some time; maybe some years after the CFMS software have been used for daily operation by the trading company to manage the company’s cash flow.

In the review stage, we will do a review on the CFMS software. We will see whether the CFMS software is still match with the company’s current needs, what improvements need to be made, is the performance of the CFMS software is satisfactory, etc. After asking questions like this and finds the answer, there are three possibilities of the CFMS software reviewer’s result. First, the CFMS software is working well from the first time it is used until now, so no changes needs to be made. Second, there is a part of the CFMS software that needs to improved, so we need to update or modify the CFMS software. Third, the CFMS software is no longer satisfactory for managing the trading company’s cash flow; in this case we can consider re-starting the life cycle to develop new CFMS software.

IV. Answer for Question B

In this part, I will explain about how I ensure the dependability of the CFMS software. Dependable software is software that can be trusted by the user. So, in order to make the CFMS software to be dependable software, we have to make the user, in this case the trading company, to put their trust in the CFMS software. Of course the user won’t put their trust in software with a bad quality, so the CFMS software must have the quality and characteristic of the dependable software.

Dependable software’s characteristic includes:

ü  Software Reliability

ü  Software Availability

ü  Software Maintainability

ü  Software Safety

ü  Software Correctness/Accuracy

ü  Software Reliability

We can say that the CFMS software is reliable if the CFMS software can fulfil its up-time requirement that means the CFMS software can provide a continuous service to manage the company’s cash flow without error or without any fault. So, when the CFMS software can do this, it means that the developed CFMS software is reliable.

ü  Software Availability

Software availability refers to the factor of the readiness of the CFMS software when the user wants to use it. For example, if there is a problem with the CFMS software that remains unresolved for several working days that caused the company cannot use the CFMS software that means the CFMS software is lack of availability. But if the CFMS software is able to quickly recover from any fault that occurred and become ready to use in just a short time, that means the CFMS software have the availability factor of dependable software.

ü  Software Maintainability

Software maintainability means that the CFMS software must be open for any repair or upgrade. For example, it may happen after several years have passed there is a significant change in the company’s policy or in the government policy that makes the CFMS software now become irrelevant in some cash flow management things. In this case, it may be too costly to develop a whole new system, so the option is to repair or upgrade the CFMS software to be able to adapt with the new business policy. When the CFMS software is easy to accept any upgrade, that means the CFMS software is maintainable.

ü  Software Safety

Safe software means that the software will not cause any serious failure that causes a fatal damage to the company’s business. When applied for the CFMS software, it means that the CFMS software won’t cause any serious failure such as letting the trading company’s confidential data to fall to any unauthorized or wrong person, or the software failure makes the company losses all its cash flow management data due to unavailability of backup feature. If this can be prevented, it means that the CFMS software is safe.

ü  Software Correctness/Accuracy

Software correctness or accuracy means that the software must be able to process data and produce accurate output. This factor is important for CFMS software because this software will deals with money that is a trading company’s cash flow. So, the CFMS software must be accurate in every process and output so the user (the trading company) can put their trust in the software, thus make the CFMS software dependable.

After looking at the above four characteristic of dependable software, now I will explain about what is the step, method, or action that will be used in the CFMS software development to ensure that the CFMS software will turn out as a dependable software.

Dependable software won’t be bad quality software, so improving the quality of the CFMS software will also improve the dependability level of the CFMS software. There is a method to ensure that software that is being developed will come out with a good quality. The name of the method is Software Quality Assurance (SQA). SQA is a control for the whole CFMS software development process. The SQA have some activities that is implemented during the CFMS software development process in order to ensure that the quality of the CFMS software is satisfactory, and therefore it will ensure the dependability of the CFMS software. So, here I will implement the SQA activities in the CFMS software development process to ensure that the software will be dependable software.

The SQA activities implemented to ensure the dependability of CFMS software are:

1. Apply Technical Method in CFMS software development
2. Use the FTR (Formal Technical Review)
3. Test the CFMS software thoroughly
4. Enforce the working standards of the development team
5. Control every change made to the CFMS software

1. Apply Technical Method in CFMS software development

Applying technical method in the CFMS software development will help the system analyst to gather a good quality software specification. For example, we encourage the use of correct method in gathering the software requirement such as using the standard steps in preparing an interview with a management team or a company staff, or making a good questionnaire question that is clear and unambiguous when conducting a fact finding using questionnaire method. All of these applications of technical method will help the system analyst to gather a good quality software specification. The same thing applies for the CFMS software’s designer. With encouraging the CFMS software designer to use the right tools in designing the software, we can get a high quality design of the CFMS software.

1. Use the FTR (Formal Technical Review)

Formal Technical Review (FTR) is a meeting that is participated by the technical staff and the software expert of the CFMS software development team. This meeting will review the developed CFMS software to uncover any errors or defect in the software and try to fix these problems in order to improve the quality of the CFMS software and also improve the dependability level of the CFMS software.

The objectives of FTR in CFMS software development process are:

ü  To reveal any defects or error in the CFMS software.

ü  To confirm that the CFMS software is developed according to its requirement.

ü  To make sure that the CFMS software is developed using the right technical standard to ensure its quality.

The benefit in applying FTR in CFMS software development is that it will help on early discovery of any problem such as reliability problem, availability problem, and safety problem. This will make the CFMS software needs less maintenance in the future that leads to make the CFMS software become dependable software.

1. Test the CFMS software thoroughly

The testing stage of the CFMS software life cycle is the most important stage to find and reveal any reliability problem, availability problem, and safety problem that exist in the developed CFMS software.

We need to implement the right testing strategy in order to reveal as many defects as possible in the CFMS software. We need to do both the white-box testing that test every single piece of code to verify that there are no error in the CFMS software’s coding. White box testing also allows us to check whether the CFMS software’s coding structure is easy to accept repair, modification, or upgrade in the future. The black box testing will test whether each module in the CFMS software do the right function. For example, we test the income module in the CFMS software by inputting a data as the company’s income, and then we check whether the CFMS software will produce the correct output by asking the CFMS software to produce a report about the company’s balance. The black box testing can ensure the CFMS software’s accuracy in getting input, process data, and produce output.

To ensure the reliability and availability of the CFMS software, we can do the operational condition test where we test the software to run under a condition that is similar with its operational condition. Then from here we can get information about the CFMS software’s reliability and availability. Additionally, we also need to test the security of the CFMS software by testing its login function.

1. Enforce the working standards of the development team

Enforcing the working standards here means that we need to make sure that every one in the CFMS software development team works according to the technical standard. For example, the programmers use standard method in coding the CFMS software, or it can be the development team needs to use standard technique in checking the CFMS software’s design such as using method like dry run, structured walkthrough, catalytic checking, etc.

The main purpose of enforcing the use of standard technique in the CFMS software development is to ensure that there is no flaw in design and development of the CFMS software, thus ensure that the CFMS software will have a high quality.

1. Control every change made to the CFMS software

During the testing stage of the CFMS software development life cycle, if there is any error revealed, the programmer must make change in the code in order to fix the error. This means that there is a change in the CFMS software’s code and therefore now the documentation from the development stage is not accurate anymore, so we need to make sure that every changes made to the CFMS software must be controlled, recorded, and documented. The purpose of doing all of this thing is to make it easier if the CFMS software needs to be repaired or upgraded in the future because we already have a complete documentation that shows the history of changes made to the CFMS software.

Finally, I would like to conclude that to ensure the dependability of the CFMS (Cash Flow Management System) software; I will implement the SQA (Software Quality Assurance) in the development process. The SQA activities implemented in the development process will ensure that the CFMS software come out with the best quality. The impact of improved software quality will also affect the CFMS software’s dependability, that is makes the CFMS software to be software that is reliable, available, maintainable, safe, and accurate. So, in the end the dependability of the CFMS software is ensured.

V. Answer for Question C

In this part, I will explain about the risk that may rise in the development process of the CFMS software, and also how we can minimize these software development risks.

Basically, risk is a hazard or a source of problem/danger that may happen and causes damage or loss. The similar thing applies for software development project risk. Risk in this CFMS (Cash Flow Management System) software development project is some factors that have possibility to affect the project in a negative way or even disastrous to the overall project.

There are two different types of risk in the CFMS software development project. There is an expected risk that we will know the risk will happen so we can prevent it or minimize its negative effect. But there is also unexpected risk that we won’t know if it can happen in the CFMS software development project, for this kind of risk, we cannot plan for the counter-measure because we really didn’t expect it to happen, for example the developer team’s server computer crashed.

Here is a list of some possible risk that may happen in the CFMS software development project:

1. Project out of schedule
2. Project Cancelled
3. CFMS software out bad
4. Creation of unnecessary feature
5. Creation of false feature
6. Preparing for future enhancement
7. Frustrated developer team
8. Additional request from user
9. Lack of experience and skill in developer team
10. Changes in the company’s policy or government policy

Now, I will explain each of the risk that I mentioned in the above list, together with the action that will be performed to minimize the impact of every risk.

1. Project out of schedule

This is the risk that the development of the CFMS software takes longer than the schedule. The customer (the trading company) that have been waiting for the project to be finished can be disappointed when we as the developer team of the CFMS software must hardly say that the CFMS software is not yet ready.

To overcome this risk, what we can do is to break the CFMS software into some small modules that has its own feature. For example, a module that is used to manage bank account, a module for keeping payment data, a module to generate report in spreadsheet format, etc. Then we can release these modules one by one. Maybe we can also consult with the user about what module should be released first and what module that can be released later. Preferably, we will release the important modules first and followed by module with optional features. By doing this way, even if the CFMS software development project takes longer than the scheduled time, the customer won’t really feel the effect because they can start using the software’s feature even it is released one by one.

1. Project Cancelled

There is always a risk that the CFMS software development project is cancelled when it already developed halfway. The customer may cancel the software for some possible reason, for example the trading company that wants to buy the CFMS software unexpectedly decides that they don’t want the software and decide to cancel the CFMS software project.

To protect the continuity of the CFMS software development project from being cancelled, we need to make the customer more involved in the software development process itself. In this case, we can have one staff from the trading company to get involved in the project’s process. So, by doing this way the user will have a better understanding about the progress of the CFMS software project and also the user will know that the CFMS software is designed toward the company’s benefit. In the end, we hope that the staff that is involved in the development process of the CFMS software can inform the trading company’s management team that will result in smaller chance of cancellation of the project.

1. CFMS software turn out bad

This risk happen when the CFMS software development project has been finished but the quality of the CFMS software is very low that the software have so many defects, this causes the customer (the trading company) to reject the software and that means all the works and efforts to build the CFMS software is wasted.

There is only one thing that we can do to prevent this risk to happen. That is to make sure that the CFMS software will have a good and satisfactory quality. In this CFMS software development project, we have put an effort to ensure the quality of the software that is implementing the SQA activities in the CFMS software development process. So we can prevent this kind of risk to happen.

1. Creation of unnecessary feature

This risk happens from the CFMS software’s programmer. The programmer may be tempted to create a feature that is too good or more than the requirement. For example, the CFMS software requirement state that the opening of the software is just a simple welcome screen with text and a coloured background, but the programmer thinks that it will be very good if the welcome screen is added with a flash movie. This is unnecessary feature that will make the CFMS software project takes a lot longer time to finish.

To prevent this risk to happen, there are two things that we can do, first we have to enforce the working standard among the CFMS software development team. By enforcing working standard among the development team, we can prevent the development team such as the programmer to do something more than what is required. Second thing that we can do is to have the user or the customer that is a staff from the trading company to get more involved in the CFMS software development progress so he/she can help to tell whether such feature is enough or too much.

1. Creation of false feature

Creation of false feature risk happen when the CFMS software has one or more features that doesn’t match with the software’s requirement. For example, it is stated in the scenario that the CFMS software must be able to calculate the balance of each of the trading company’s account and also able to warn the user about the specific date when one or more accounts will become overdrawn or overdraft. The creation of false feature may happen if the CFMS software is created just to be able to calculate the company’s account balance but the function to warn the user about the accounts that is going to become overdrawn or overdraft is omitted.

The main cause of this risk to happen is the incomplete requirement that is gathered during the requirement gathering stage. So, in order to prevent this risk to happen, we have to make sure that we do a proper requirement gathering technique and fact-finding to deliver a high quality software requirement. Luckily, in the CFMS software development life cycle we also use the prototyping method. The prototyping method will really help us to refine the CFMS software requirement so we can get a detailed software requirement, because we have an intense and close communication with the customer during the prototyping stage.

1. Preparing for future enhancement

This risk is a case where the developer team adds some more features to the CFMS software that is actually not needed now, but the developer adds these features to make the CFMS software ready for future needs of the company so that the CFMS software won’t need any upgrade in few years later. For example, now the CFMS software is required to just store the details about each of the company’s bank account, but the developer decide that maybe the trading company will need to do an online banking through the CFMS software, so the developer team just adds this feature that will consume more development time and also the technology may be still too expensive for today’s time. And also the risk is that maybe the trading company don’t need such feature even in few years later, that means the feature that consume more cost to the project will be wasted.

To prevent this, we will just keep the CFMS software development simple. We will just do what is required from the software according to the CFMS software’s specification that is stated in the scenario. We can prevent for future upgrade by designing the CFMS software in such a way that it can be upgraded in the future if the company needs us to implement more sophisticated feature in the future. By doing this, we can save development effort and keep the project cost as low as possible.

1. Frustrated developer team

It is a real risk that is possible to happen; the member of the CFMS software development team that is most likely to get frustrated is the programmer. Usually this problem is caused by the project leader giving a very limited time for the programmer to finish coding the CFMS software. The project leader doesn’t consult with the programmer about how much time that they actually need to finish the CFMS software’s code. In the end, the programmers may find that it is impossible to finish the project on time and give them a high stress level. Stressed or depressed programmer can result in poor quality of the CFMS software’s code.

In order to prevent the CFMS software development team especially the programmer to get frustrated, what we can do is to ask for the programmer’s opinion about how long it takes to finish the coding of the CFMS software. Their opinion can be our consideration in deciding the time target/the schedule about when the coding of the CFMS software should be completed. As long as the coding time from the programmers is still logical, we must respect their opinion and use it in deciding the schedule because the programmers are people who really do the actual coding of the CFMS software.

1. Additional request from user

It may happen that when the CFMS software development process has gone halfway, then suddenly the customer which in this case a representative from the trading company, come to us as the developer and say that yesterday they just see the CFMS software from another company that according to them it is nicer in term of its user interface and features. Then it causes the company to request that the CFMS software that is being developed now is changed and added with some more additional feature. This can be very troublesome since we have start the CFMS software project and it has progressed very far. But, when a case like this happen, we have to go back few stages in the development life cycle to re-design the CFMS software and also find a way on how to synchronize the new features that the user wants to be added to the software with the initial design of the CFMS software.

If a case like this happens, we can minimize this risk by defining a clear project scope for the CFMS software. So, if suddenly the user asks to add some more features that will make the development of the CFMS software delayed for a very long time, then we can explain to the customer that those features is out of the current project scope. But, instead of just rejecting the user request and makes them disappointed, we can plan to add those additional features asked by the user as an update in the future after the first version of the CFMS software has been released. By doing this way, we won’t ruin the schedule of the overall CFMS software development project and also we still can make the customer satisfied by updating the system after it has been released and used by the trading company.

1. Lack of experience and skill in developer team

This risk can happen when we as the project leader just realised that the developer team of the CFMS software doesn’t have enough experience in developing financial software such as the Cash Flow Management System (CFMS) software. This will cause the CFMS software development project takes much longer time to finish because the developer team needs to do their study about how to develop a software that is used to manage a company’s cash flow. For example, the software designer doesn’t understand how it is to manage bank account information and how to calculate if an account will become overdraft or overdrawn. So, he need to study about these issues first then the designing stage of the CFMS software can be started.

The solution to minimize this risk is to have a mentor or outside advisor that can use their knowledge to assist the development team in developing the CFMS software. These people may help the developer team by giving them information about how financial software like CFMS software should do. Or if the problem is the developer team doesn’t familiar with the technology that is used to develop the CFMS software, we can hire an outside mentor to help the developer team to get familiar with the development technology and tools.

1. Changes in the company’s policy or government policy

There is always a risk that when the development of the CFMS software is still in progress, there is a change in government policy or the company’s policy. For example, one of these changes can be changes in the tax rate that has been set as a fixed amount in the CFMS software. When this situation happens, the software will need to be re-coded to adapt with the changes.

There is no way to avoid this risk, because these changes can happen anytime. We can only minimize the effect of this risk that is by making the CFMS software to be maintainable so we can fix, repair, or modify it to adapt with any changes that happen unexpectedly.

In the end, we can conclude that there are so many risks that may happen and disturb the progress of the CFMS (Cash Flow Management System) software. There are two types of risk that are risks that we can expect to happen, and also unexpected risk that is really out of our expectation. In this part, I have explained about some risk that is possible to happen in this CFMS software development project and also how to minimize the bad effect of each risk. So, in spite of any risk that may happen, we can always try to minimize it and keeps the project going as good as possible.

REFERENCES

ASPAlliance, 2008, Software Development Life Cycle, Retrieved on June 17, 2008, from http://aspalliance.com/articleViewer.aspx?aId=1017&pId=-1

BCS, 2007, What Makes Software Dependable?, Retrieved on June 8, 2008, from http://www.bcs.org/server.php?show=ConWebDoc.9933

Bobyjos, 2004, SDLC Models Advantages & Disadvantages, Retrieved on June 17, 2008, from http://bobyjos.blogspot.com/2004/11/sdlc-models-advantages-disadvantages.html

Cis.gsu.edu, 2008, System Development Life Cycle & Prototyping, Retrieved on June 7, 2008, from http://www.cis.gsu.edu/~dstraub/JMBA/MBA8473/2001/sdlc4ups.pdf

Csus.edu, 2008, Systems Development: Planning, Lifecycle, Retrieved on June 17, 2008, from www.csus.edu/indiv/e/eatonr/MIS%20175%20Notes/sysdev.ppt

Elucidata.com, 2002, The Software Development Life Cycle(SDLC): For small to medium database applications, Retrieved on June 17, 2008, from http://www.elucidata.com/refs/sdlc.pdf

GeekInterview.com, 2008, SDLC – Prototype model, Retrieved on June 8, 2008, from http://www.learn.geekinterview.com/it/sdlc/prototype-model.html

Hall, Prentice, 2002, Application Development by Information Systems Professionals, Retrieved on June 8, 2008, from www.prenhall.com/divisions/bp/app/martin4/ppt/ch09.ppt

Intecs HRT, ESA, 2003, Software Dependability Techniques, esamultimedia.esa.int, Retrieved on June 22, 2008, from http://esamultimedia.esa.int/docs/industry/SME/2003/software_engineering/A-Software_Dependability_Techniques.pdf

Jai Son, UBC Commerce, 2008, Appendix: IS Development Methodologies, Retrieved on June 8, 2008, from http://mis.sauder.ubc.ca/courses/BAIT501Protected/IT_acquisition_app.pdf

Littlewood Bev & Strigini Lorenzo, Software Reliability and Dependability: A Roadmap, Retrieved on June 8, 2008, from http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/finallittlewood.pdf

Murthi, Sanjay, 2002, Managing Risk in Software Project, Developer.com, Retrieved on June 22, 2008, from http://www.developer.com/java/other/article.php/1572471

Newman College, 2008, Prototyping, Retrieved on June 8, 2008, from http://portal.newman.wa.edu.au/technology/12infsys/html/KWH2003/Prototyp.htm

Ou.edu, 2008, Project Management, Retrieved on June 17, 2008, from www.ou.edu/class/mis5003/mbapm.ppt

Pragmatic Software Newsletter, 2003, Tips for Managing Risk in Software Projects, Retrieved on June 22, 2008, from http://www.pragmaticsw.com/Newsletters/newsletter_2003_08_SP.htm

Sis.pitt.edu, 2002, InfSci 2510: Information System Analysis and Design, Retrieved on June 8, 2008, from http://www.sis.pitt.edu/~pwu/ISAD/lect/lect9a.pdf

Stylusinc.com, 2008, System Development Life Cycle (SDLC), Retrieved on June 17, 2008, from http://www.stylusinc.com/Common/Concerns/SoftwareDevtPhilosophy.php

Stylusinc.com, 2008, Software Development Risk, Retrieved on June 22, 2008, from http://www.stylusinc.com/Common/Concerns/software_development.php

Wikipedia, 2008, Software Quality Assurance, Retrieved on June 8, 2008, from http://en.wikipedia.org/wiki/Software_quality_assurance

Do you have any comment on this? maybe you have something to ask me or want to discuss with me about this?Or maybe you are IDIC student and taking this module also?
Feel free to use the comment box below (click here if you cannot see the comment box).

Coming next, I will post another IADIC assignment, C2005 Object Oriented Programming in Java

Stay tuned! you can subscribe to my blog’s feed by clicking here so you won’t miss when the new post is published

admin Education, IADIC, Informatics C2002, IADIC, Informatics, project risk, software engineering, software life cycle, SQA