THE WINEPRESS: A software development process for a wines warehouse from inception through to installation.
Functions of the system
The system will:
Record and retrieve orders for wine from customers namely bars, restaurants, country clubs, embassies, liquor stores, hotels and caterers from the warehouse, which is a large inventory of wines from all over the world.
capture records of fees received and due from each customer that was delivered to
the real-time delivery made by drivers to customers
Any problems encountered such as breakages, refusals, closers
All this information will be reported in real-time. The system is to be used primarily by supervisors and managers of wine sales distribution company to keep track of inventory, sales thus make their work of evaluating progress easier and more efficient. Most importantly, this system will be used in making managerial decisions and necessary interventions as all the information will be available on one platform.
Key features of the system include:
Physical environment, i.e. other systems with which it will interface
Time efficiency: the set out times will be adhered to in order that the system might be rolled out at the intended period.
Space efficiency: the program will be designed to be light enough to be supported on mobile devices.
Security: security features like password access must be included especially for the supervisory and managerial components.
Reliability: A secure data backup will be installed complete with a clear retrieval plan so as to ensure that no data is lost once entered. Also, numerous test runs and maintenance will be done in order to eliminate bugs and any problems that could impair reliability.
Software engineering process
After exploring the various software engineering processes available, the spiral model was chosen to be used on this project because it combines some key aspect of the waterfall model and rapid prototyping methodologies, thus combining the advantages of top-down and bottom-up concepts.
The basic principles of the spiral model include:
Considering the significant conditions of all key components and stakeholders.
Identification and evaluation of alternative approaches for arriving at the desired outcome.
Identifying and resolving risks that are attendant to the selected approaches such as the waterfall or evolutionary prototyping.
Obtaining go-ahead from all such stakeholders who have a say on the project, together with the commitment to proceed to the ensuing levels.
Fig 1: The spiral model of software engineering
Software development paradigm was chosen
The object-oriented paradigm is best suited for this problem as it helps meet the performance goals best: development is faster as it employs reusability and less function dependency, is more secure compared to structured and provides room for more abstraction and flexibility.
Timetable of activity
Task name Duration Start Completion
Preliminary meetings with client, evaluation, and inspection of needs 2 days 3/01/2018 5/01/2018
Meetings with software team 1 week 5/01/2018 12/01/2018
Meeting with potential users 3 days 5/01/2018 8/01/2018
Reevaluation of needs, meet with the client 2 days 13/01/2018 15/01/2018
Designing prototype 1 week 15/01/2018 22/01/2018
Testing and debugging 2 days 23/01/2018 25/01/2018
Installation and maintenance 1 week 26/01/2018 2/02/2018
Problems likely to be encountered and how best to minimize their effects
The team was cognizant of the following problems that were likely to arise:
Insufficient requirements – this poses a challenge if the client requirements are not clearly spelt out thus coming across as ambiguous or lacking the clarity necessary for the understanding of the problem. To take care of this problem, wholesome requirements to which all parties are agreed must be crafted at the first meeting.
Unrealistic schedules – this might arise in an instance where activities are not allocated sufficient time for their proper execution. The converse of this, which is, assigning too much time to tasks, is also discouraged as this makes the project drag for far too long, adding to the cost. Sufficient time should be allotted by proper planning to avert this problem. The best way to realize this is to apportion reasonable contingencies for each milestone.
Insufficient testing will present your client and other users of the system such difficulties that will cause them to either develop a really bad view of the system or even to abandon the system altogether. This can be very damaging to one’s reputation as a systems engineer. To avoid such a damning eventuality, it is absolutely necessary that as many tests as may be reasonable be done. The spiral model ensured this was attained as it required that tests be carried at every other stage.
Adding fresh concepts as the project progresses. This was evaded by having elaborated and as comprehensive as possible requirements from the very onset, hence there was no need to constantly change the requirements.
Communication if not kept flowing may lead to chaos and the project taking longer than the allocated time. It is therefore of utmost importance that the personnel working on the different components of keep in constant communication among themselves and also with the client, updating them on the progress as necessary.
How to manage the development project and keep to timetable
The following strategies were laid down and employed to ensure proper management of the project and to keep to the timetable:
Sticking to the setout commitments no matter what.
Document a detailed task list.
Early identification of critical paths and bottlenecks.
Make decisions effectively and promptly, so as to ensure no unnecessary delays.
Employ measures that will ensure the set timelines are adhered to by all.
Manage meetings effectively in order to exhaustively cover all important points to be deliberated upon, avoiding dwelling on unimportant matters.
Accept progressive refinement of the timetable, adding details as may be needful and merging activities that can be done concurrently.
THE SOFTWARE ENGINEERING PRACTICE DOCUMENTS
Based on the spiral model, and includes documentation right from the concept model, the generation of the different components or modules as well as those of the different steps of testing.
Requirements to design: the link
This system is needful for the purpose of enhancing the managerial task of monitoring as well as measuring performance against key performance indices. As the software will give real-time information on deliveries made, even the productivity of personnel such as drivers of the distribution trucks can then be measured. Again, the system eliminates chances of erroneous reporting, deliberate or otherwise, since the system is configured in such a way as to detect such inconsistencies. In the end, the overall profitability of the warehouse, operational dynamics are significantly enhanced. The management of the warehouse has, therefore, a better grip on the supply and so having this system is indispensable.
Real-time data entry: the warehouse employees and their clients will be able to enter data pertaining to invoices, breakages, and orders. Enhanced decision making and faster deliveries leading to better customer satisfaction will be the result.
1. Cross-browser /platform support (namely Internet Explorer, Firefox, Opera Mini, Chrome, Safari – PC and Mac)
2. Mobile support for advanced smartphones – operating on either IOS or Android
3. Allow users with administrative rights to create and remove user accounts as may be necessary. Such an action must be approved by two other users with administrative rights. This is needful to enhance data security.
The system should fully function on major browsers
Full support for mobile platforms in IOS, as well as Android, is of paramount importance.
Small portable scanners for scanning signed invoices and order forms, which will be uploaded real time onto the supervisors and managers end.
Computers with either Windows 8 OS, Macs
Documentation of system design
Top-level decisions made:
It was decided that the software be designed such as to incorporate multi-level users rather than top-level users only
How these were broken down into components
Level 1: Managerial and supervisory users
Level 2: Delivery people, employees of the warehouse
Level 3: The warehouse clients and owners of retail outlets
How are these components linked?
Both level 2 and 3 components are to enter the data, which should match; otherwise, the system will be rejected. This data is then transmitted real-time to level 1 user of the systems who then make use of this to either commission deliveries in the event that the data entered was an order, or update accounts if the data took the form of a confirmed invoice amount.
Upon installation of the software, we will include a short video clip detailing how to navigate and use the system, each customized to the needs of each category of users. In addition, pop up prompts will be included to direct the user accordingly, in addition to the user manual that will be provided which basically entails simple instructions on log on, together with user support links.
These are examples used as part of design activity, and which also ought to be clearly documented.
Objectives and success criteria
The designed system met the overall client requirements for real-time data entry as well as monitoring when tested.
The components were tested and found to interact flawlessly. It would, therefore, pose no challenges when once installed.
Testing techniques and test cases
The program was tested on both the functionality and implementation approaches. Black and white box testing was performed at each stage of expected deliverables, and upon each component, at which point errors were fixed as was necessary to the proper running of the program. Afterward, the entire system was tested and found to work as desired.
This was done at each step of coding, and the final test run completed within the two days that were assigned in the initial timetable
Test results and debugging procedures
All tests and debugging were carried out in accordance with the predetermined procedures, whose details were well documented.
Fig 2: The general testing overview
FINAL PROJECT REPORT
This gives us a general overview and evaluation of the entire project from conception to delivery.
Lessons learned from the process chosen
The process chosen was indeed very beneficial as it helped organize the work into discrete segments which were much easier to work on. Also, the fact that the model requires approval from stakeholders before advancing with the work helped save costs, review the progress from time to time, and incorporate new ideas at each step, the ultimate result being that no project time was wasted. The process also is useful in effective conducting of tests on small components as opposed to robust testing that other processes like the waterfall process presents. Also, in employing the top-down and bottom-up approaches concurrently, the process enabled the development of a most effective system.
The initial customer requirement was to develop software solely for use by supervisors and managers. However, upon closer inspection, the development team found it fit to include clients as well as personnel components, to which the client was receptive.
The software process was so satisfactory it exceeded our expectations, especially because of the flexibility it offered us. The major problem encountered was at the onset when the warehouse clients had to be involved; they were not very receptive to the idea initially. Fortunately, we were able to convince them. The process was followed as closely as was possible, with the exception that once set, the overall deliverables did not change significantly thus there was little cause for revision.
Developing the system
This document as presented can actually be used to develop a software system not only for a warehouse but also for a production plant- incorporating necessary adjustments, and with improvements upon the following:
The test stubs which are not sufficient to run an executable program
Using an object-oriented code to write the program, so as to enhance security.
Actual time spent on the project was almost similar to the predicted times, with one or two exceptions. However, it is important to note that this was only achieved due to the ample contingency times earlier assigned. The lesson to be taken away is to always allocate sufficient contingency time to activities and stick, as far as is possible, to the timetable. Of key importance is that each member of the team be assigned a specific role so as to ensure that the task is done in an orderly and systematic fashion. This, I believe, enabled a timely delivery of the system to the client.
The process of developing the system was intense, as it was exciting. As with any undertaking, the project presented its own unique challenges which the development team was able to tackle rather well.
Rose, Laura https://www.ibm.com/developerworks/rational/library/jul05/rose/index.html