Advancing CV Generation

Abstract

This report is about the applied practices, models and techniques to our software product for online CV generation prototype development. The development was inspired by the growing need for a product that can generate a responsive resume to many jobseekers in the labour market looking for employment opportunities. The introduction part of this report exposes the need for having this product owing to huge user-needs. The report then critically reflects on the applied models, tools and practices in software engineering and data analysis dissertation help that guided this product development. The report them identifies the research gap before concluding with an overview summary of main ideas in the report.

Introduction

Prototypes refer to design ideas that seek to address the established design challenges based on design opportunities. This work reports on the prototype for the development of an online product that can publish, edit and generate curriculum vitae. The main product users are the numerous graduates and job seekers in the labour market. The advent of web-based technologies has greatly impacted software engineering domain. The traditional application for CV generation has failed to capture the dynamic users’ demands and have belittled the effort by academic graduates and job seekers to “sell” their personal potentials before prospective employers. This report intends to report on the related models, tools and techniques applied to our software product development.

Background Information and Statement of the Problem

According to Reifer (2017), the evolution of web-based technologies has streamlined the entire recruitment process and cycle. Alongside the spinning wheel of globalization, the world is changing at fast rate, allowing geographical mobility of labour and other factors of production. Globalization and scientific evolution in the realm of communication technologies are inextricably fabricated. Increased demand for excellent talents has excited the need for resumes that captures necessary competence and creative skills and which provide holistic review of a person’s accomplishments in different arenas. A traditional resume does not properly cite bearers’ strengths, achievement and skills in a clear manner. Traditional resumes also provided tinted list of personal details and accomplishments that may not align with modern employment and career dynamics. Our product seeks to close this gap by creating and online platform that can generate modern CV in a cost-effective manner and in line with users’ demands.

"

"Dig deeper into Addressing Substance Abuse Among Young Adults with our selection of articles."

Rationale (Drivers) of our Prototype Development

The manner in which individuals “market” themselves in the labour market is changing gears. This is attributed to fast changes in information technology sector that has influenced the application of ICT tools in daily endeavours. Personal smart phones and laptops have ascended to become tools which people harness to generate their CVs. Well-presented CV have increased chances of securing employment. This project is spreading awareness to graduates and job applicants of the application of online-generated CV in applying for a job. Additionally, this project induces awareness to educators amongst the general public about the program which caters for their employment application needs.

Software Engineering Models

Our program harnessed the prototyping model as one of the software development life cycle models. Prototyping refers to the process of developing an operational replication of a product system (Riabov, 2011). We employed this model based on the axiom it provides a small scale facsimile of the final program. In addition, this model has the capacity to provide users’ feedback as diagrammatized below (figure 1);

According to Boehm, and Turner (2013), prototyping model is one of the most popular SDLC models. The model is used when users have no idea about the project requirement beforehand. According to this model, a prototype of the final program is first conceived, tested, and modified in accordance to the customers’ demands that are captured in their feedback. The process is continually repeated until the users are fully contented about the software; and that is when the final program is developed.

In accordance to the prototyping model, we implemented our program partially during the analysis phase in order to grant our users an opportunity to react to the program at an early stage. We interviewed our prospective users to capture new requirements to be re-integrated into system development. The interview responses were thus captured in a document to be used to rectify the program before we developed the final product

Prototyping model was advantageous in a number of ways. First, our intended users had an opportunity to see the partial product early in the development life cycle. This opportunity ensured high level of user comfort and satisfaction. In addition, new demands from users were easily integrated and missing links and functionalities easily figured out (Koelsch, 2016). Errors would also be easily detected in time thereby cutting down of excessive costs in alleviating them when they have matured. Early identification of defects also elevated our program quality standards. The early the errors are identified, the early the relevant remedies are applied which prevent escalated defects that may permanently paralyse the product development. Indeed, prototyping model was one of the best software development life cycle models since it was flexible by virtue of confining our project within a strict scope. However, the model was characterised by a few imitations. The major limitation was its costliness concerning time and financial resources. Besides, it would also be cumbersome sometimes to incorporate all the changes proposed by users.

A classical waterfall model was also employed in program development based on its simplicity and idealistic nature. Waterfall model disintegrated our product development life cycle into simpler phases (Pohl, 2016). In accordance with the model, our main idea was that one phase could be started after the completion of the previous phase. Thus, “the output of one stage was the input of the next.” Owing to this model, our program development was gradual and sequential as a “waterfall”. Various sequential stages are shown in the following diagram (figure 2);

In the first stage (feasibility study), we intended to understand the problem to come up with various strategies of resolving it. The intention was also to establish whether the development of online CV generation program was technical and financially viable. The requirement analysis and specification stage sought to comprehend precisely customer requirements while documenting them. The design phase aimed at transforming software requirements into an implementable structure through programming language.

In coding and unit testing phase, we translated the software design into source code with the help of programming language whereby each designed module was coded. Integration and system testing phase encompassed the integration of various modules after being coded and unit tested. The last phase (maintenance) was an important stage for it sought to maintain the overall effort applied to the whole cycle. Corrective maintenance, perfective maintenance and adaptive maintenance strategies were employed in this regard (Koelsch, 2016).

Waterfall model was simple and easy for us to understand; based on the view each stage is easy to define. The model also reinforces good habits including define-before-design, design-before-code. It was also easy to record processes, action and results as reflected in the development cycle. However, the waterfall model provided no room for feedback path and assumed that no error would arise at any development stage. The model also does fail to pave a way for the inclusion of change requests

Owing to the limitations imposed by the classical waterfall model, we maximised on the use of iterative waterfall model. This model offers feedback paths from each stage to its preceding stage; which is the main difference from the classical waterfall model. Whenever defects were detected at any stage; necessary remedies were injected immediately to lower time and effort required in delayed correction (Koelsch, 2016).

Software Engineering Tools

Software engineering refers to the systematic approach to design, execution, operation and maintenance of a software program. We ensured our development conformed to six core software engineering objectives namely maintainability whereby the product would be viable for it to evolve and meet the dynamic requirements in market segment. The other objective was correctness whereby the product ought to be correctly implemented as specified in the SRS document. Third is reusability whereby the product ought to be reused in case different modules are employed to come up with a new product. Fourth is portability whereby the software ought to be transferred from one computer system to the other. The fifth characteristic is reliability whereby the product characteristics are functional over current times and finally testability whereby we expected our program, to adhere to criteria for test and evaluation.

Software engineering tools were also used in test the product to ensure its firmness; thoroughness and performance were at the peak and in line with projected costs and user-needs. Software quality was assessed by different testing tools; which can be classified into two namely static test tools and dynamic test tools. According to Budgen (2013), static test tools are applied to static testing practices whereby typical approach is pursued. Static test tools do not test the actual execution of a product and they include tools such as flow analysers that offers great flexibility in data low from output o input; coverage analysers which check on the rationale elements of the software; path tests which check on the consistency of applied codes, and interphase analysers which tests on the impacts of passing data and variables in the modules.

On the other hand, dynamic test tools were used to test the software with current or existing data. Dynamic test tools incorporate the following tools; test driver which offers the input data to Module Under Test (MUT), emulators which gives reaction facilities that are harnessed to copy (imitate) parts of the system yet to be developed. Lastly, mutation analysers are applied to test the product’s fault tolerance by the deliberate introduction of known errors into the software code.

Software Testing Guidelines

Software testing refers to the process of implementing a program with the objective of deducing a defect or error (Beaudouin-Lafon, and Mackay 2009). To make our online CV generation prototype functional, it ought to be free from defects and this can be ascertained through successful testing to remove traces of errors within. Our product testing practice was guided by various software engineering testing guidelines (principles). For instance, we dedicated software not to the development team but a group of testing team. The development team was mandated the role of product testing on the view developers would fail to acknowledge the presence of errors unconsciously. Developers would perform unit testing but software testing was set aside for a testing team.

According to Beaudouin-Lafon, and Mackay (2009), it is almost impossible to have one hundred per cent bug-free software. As testing progressed, it would not be proven to be free form defects. As a result, this premise cautioned us to establish test objects and scope early enough. In addition, we began as early as possible prioritizing sections to be tested with highest priority as early as possible. We took cognizance of the view that time for testing our product was a limited resource and that the art of coming up with a test plan was an excellent idea before the commencement of actual testing. Testing was propagated on the basis of unexpected and negative output. The correct data was harnessed in forming the basis of our testing to increase chances of any defects emerging. Test cases were properly documented for easy retrieval in the future stages. Thus, test cases were well enlisted with precise definitions and descriptions of inputs provided and different expected outputs. Testing was done for non-functional and functional product requirements (Gillies, 2017).

Quantitative assessment of tests and their findings was also conducted and documentation of results properly done. Further, testing was reinforced by automatic tools and techniques to ensure the product operated within the required functions. According to Carrington (2017), test cases ought not to be developed on the threshold of mere hypothesis or assumptions. Based on this axiom, the test cases were always properly validated. We never inclined ourselves into thinking that our product was free from bugs. Test cases might lead to extremely weak test cases.

Software Quality Assurance Practices

According to Brohi, Butt, and Zhang (2019), software quality assurance (SQA) refer to ways of ensuring quality in a software product. This constitutes of a set of activities and practices, procedures and measures that are deemed efficient for the project implementation in a sound manner to meet the users’ expectations and cost-effectiveness. Software Quality Assurance is an umbrella term for a number of practices that are applied to the entire software development drive. The concept of software quality assurance integrated a quality management approach, multi-testing framework, official technical reviews, excellent software engineering technology and measurement and reporting framework.

Our program constituted of various software quality assurance activities. The major activities included the Software Quality Assurance plan which provided a rubric of how Software Quality Assurance would be conducted in the entire product development cycle (Huo et al., 2014). Alongside the Software Quality Assurance plan, we had to set the check points upon which the development performances would be assessed based on data collected on these established checkpoints. In addition, multi-testing strategy ensured we would not rely on a single testing approach when otherwise there are numerous testing approaches under disposal that can be used.

Further, it ventured into measuring change impact. The changes for making corrections to meet emerging user needs sometimes re-introduced new defects. As a result we ought to reset the new alterations and check for loopholes posed by new changes and fix them in good time. In addition, the practice of managing good relations was impeccable in our project. Managing good relations with other teams we interacted with was not only essential but also mandatory for quality outcomes. We avoiding politics and remained focused to our intentions!

As a result of adhering to the aforementioned practices, we optimised chances of quality production, and indeed saved on time and financial resources incurred. The quality of the product and the whole process improved to a higher pedestal. However, adherence to Software Quality Assurance demanded extra addition of resources in terms of human and finance to maintain quality (Galin, 2004).

The aspects of quality were well understood from various perspectives. These perspectives described various concepts concerning quality from a common threshold that could be interpreted in a common way. The first view was the customer perception which connects the developer with the users to extract a common interpretation of quality. Quality parameters were granted heightened concern, because they defined the capacity for the product to be positively receipted by users. In addition, quality would ensure time and financial resource management in the development life cycle.

Developers view measured the degree by which the prototype’s characteristics conformed to predetermined requirements and standards. The developer view is influenced by three main factors namely the code which is measured by the prototype’ correctness and reliability; data which is measured by the application integrity and thirdly maintainability which is measured by the product’s capacity to conform to computer programs.

Users’ view was applied to confer quality from the perspective of product users. This comprised the capacity of the product to meet users’ needs and requirements. The product view conceived quality from the inherent characteristics of software product. Product quality encompasses features and traits possessed by the product which contribute towards the basketry of software requirement fulfilment. Product quality was measured by the value-based perspective that sees software quality as dependent upon the users’ willingness to purchase or pay for it. On the uses’ perspective, quality is defined by the capacity to meet preferences and expectations in requirements.

Research Gap

The domain of software engineering is dynamic owing the innovations. The changes are inspired by the constantly changes in consumers’ preferences and needs (Naik, and Tripathy, 2011). The labour market is also changing with people scrambling for to acquire knowledge, skills and attitudes that are compatible with what employers are seeking. The preparation of an excellent resume that captures personal details, work experiences, competencies and other jurisdictions increases chances for employment consideration. This project focused on the creation of a product that can assist job seekers manage their CV; and generate a responsive online platform that can achieve this quest. The work reports on the applied software engineering models, techniques and tools applied in this development. The greater focus was on the waterfall model, prototyping model and iterative model. This project proposes systematic review to establish the effectiveness of other models such as Spiral and RAD models. Besides, this project encourages more studies to complement the current study on how different models, tools, and techniques influence software product development.

Conclusion

Software engineering domain is revolutionizing at a rapid pace. These changes are necessitated by dynamic preferences and software users’ tastes. Besides, the domain of software engineering requires optimum accuracy, and in-depth need and requirement assessment to ensure products adhere to high quality standards and get to meet users’ needs. Due to high accuracy demands, the application of theoretical models, tools and techniques becomes relevant. This report has demonstrated how a prototype for online CV generation is developed based on the threshold of software engineering models, tools and practices. Adherence provided software engineering practices ensures accuracy in software development life cycle which not only saves on time but also on financial expenditures. Software developers ought to continually ensure applied models and practices are responsive in meeting users’ needs, products needs and system requirement needs.

References

Beaudouin-Lafon, M. and Mackay, W.E., 2009. Prototyping tools and techniques. In Human-Computer Interaction (pp. 137-160). CRC Press.

Budgen, D., 2013. Software design. Pearson Education.

Boehm, B. and Turner, R., 2013. Using risk to balance agile and plan-driven methods. Computer, 36(6), pp.57-66.

Brohi, A.B., Butt, P.K. and Zhang, S., 2019, July. Software Quality Assurance: Tools and Techniques. In International Conference on Security, Privacy and Anonymity in Computation, Communication and Storage (pp. 283-291). Springer, Cham.

Carrington, D., 2017. Software engineering tools and methods. SWEBOK, p.1.

Cohn, M., 2017. User Stories and User Story Examples by Mike Cohn. Mountain Goat Software.

Endres, A. and Rombach, H.D., 2003. A handbook of software and systems engineering: Empirical observations, laws, and theories. Pearson Education.

Galin, D., 2004. Software quality assurance: from theory to implementation. Pearson Education b3India.

Gillies, A., 2017. Software quality: theory and management. Lulu. com.

Huo, M., Verner, J., Zhu, L. and Babar, M.A., 2014, September. Software quality and agile methods. In Proceedings of the 28th Annual International Computer Software and Applications Conference, 2004. COMPSAC 2004. (pp. 520-525). IEEE.

Koelsch, G., 2016. What Makes a Good Requirement?. In Requirements Writing for System Engineering (pp. 31-74). Apress, Berkeley, CA.

Naik, K. and Tripathy, P., 2011. Software testing and quality assurance: theory and practice. John Wiley & Sons.

Pohl, K., 2016. Requirements engineering fundamentals: a study guide for the certified professional for requirements engineering exam-foundation level-IREB compliant. Rocky Nook, Inc..

Riabov, V.V., 2011. Methodologies and tools for the software quality assurance course. Journal of Computing Sciences in Colleges, 26(6), pp.86-92.

Reifer, D.J., 2017. Software Quality Assurance Tools and Techniques. Software Quality Management, New York: Petrocelli Books, Inc.

Sears, A. and Jacko, J.A. eds., 2009. Human-computer interaction: Development process. CRC Press.