11/30/13

Royce's 5 remedies for the riskiness of software development and its application to my term paper


(Royce, 1987) is one of my favorite papers which describe 5 additional practices to add to traditional SDLC to address its riskiness and increase the chance of success. In this post I will summarize key point of the paper and described how I applied it on defining the development process for implementation of new “Recipe” function of Tesco mobile app on my term paper. 

 
There are two essential steps common to all computer program developments, regardless of size or complexity. There is first an analysis step, followed second by a coding step. Many additional development steps are required, but none contribute as directly to the final product as analysis and coding, and all drive up the development costs. Customer personnel typically would rather not pay for them, and development personnel would rather not implement them.  The prime function of management is to sell these concepts to both groups and then enforce compliance on the part of development personnel.
As each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps but rarely with the more remote steps in the sequence.  
The implementation described above is risky and invites failure. The  testing  phase which  occurs  at  the  end of  the  development cycle  is  the first  event for  which  timing,  storage,  input/output  transfers,  etc.,  are experienced as distinguished  from analyzed.
(Royce, 1987) introduced five practices which are summarized in the following figure.

·         Design first: After the gathering of system and software requirement, there should be a preliminary design phase which should begins with a program designer rather than an analyst or programmer. The advantage of this practice is that in analysis phase, given the preliminary design, the system analyst can collaborate with the designer to discuss concerns about the storage, timing, and operational constraints of the system to ensure that the future software will not fail because of storage, timing, and data flux reasons. This reduces big threats of the projects!
·         Document the design: Though the author mentioned only the design, I strongly believe that documentation is an essential practice to the success of the project which should come along as the project progress. Therefore, we should have various type of document: requirement, preliminary design, interface design, final design, operation instruction..
·         Do it (the process from preliminary design to usage) twice.
·         Plan, control and monitor testing: Having a clear plan to assess and test future functionality of the system before it actually be implemented is a good practice. Morden software development introduces a similar concept: TDD: Test driven development. It helps to clarify what we need to do and the way to do it right.
·         Involve the customer: As depicted in the figure, customers should involve since the first stage of the development process: gathering requirement. He should involve deeper as the project progress: Giving reviews on preliminary design and different subsequent designs. Finally, they must review the final software before it gets accepted.
Application is term paper
In our term paper, We suggest using Water fall development process together with five remedies described by (Royce, 1987). There are some reasons for such choice:
-          The project’s requirements are clear
-          Product definition is stable
-          Technology to implement is understood
Because implementing “Recipe” function in Tesco mobile app is not a very big project, thanks to the ease to use and understand of waterfall model, using it will probably increase the efficiency of the development team. However, this is also not a small and simple project as it seems: We do not only add some buttons and screen on client application (namely one add button on the upper right corner of the ingredient window and two button on navigation bar), but also change the database structure of ingredients on the server side, which may cause problems if not implemented carefully.
We chose to apply Royce’s 5 remedies to ensure the success of our project.
-          Testing: Testing must be planned, controlled and monitored. There are several levels of testing: Unit test, integration test and system test. We introduced Test-Driven Development in our project: Writing test case before actually implementing the code. With such aim, we recommend using some framework for unit testing. For server side which use ASPX technology, we will use xUnit (http://xunit.codeplex.com/  -a free, open source, community-focused unit testing tool. Besides, for Android app we use JUnit – A unit testing framework for Java language (http://junit.org/) and for iOS app, we could use XCode.
-          Repetition twice: Since this project is not to build a new system (original) but to add new function to an existing system, we suggest that to “repeat twice” is just optional.
-          Users’ involvement: As the Royce’s suggestion, users should take part in various phases However, Tesco is free software provided to customers with the aim that they will use it to shop in Tesco. The fact that there are no specific customers requests for the product leads to a need to have a “product owner” who acts as “users” to provide requirement and review.

Reference


No comments:

Post a Comment

About Me

My photo
Dublin, Ireland
I am a Master student in UCD Michael Smurfit School. With broad experience in start-up, research, software industry and sale, I am actively seeking employment in consulting industry.