Empirical Development of a Mobile Application: UVA- Wise Undergraduate Software Engineering Capstone Project

Transcription

1 Empirical Development of a Mobile Application: UVA- Wise Undergraduate Software Engineering Capstone Project I. Weissberger, S. Showalter, T. Deel, M. Ward, M. Whitt, and A. Qureshi University of Virginia s College at Wise, Wise, VA, United States of America Abstract - Capstone projects allow students to put to use the knowledge they have acquired in the classroom. Projects such as these will serve to reinforce the concepts that may otherwise seem vague or abstract to students when they first encounter them. Capstone projects in software engineering give students the full experience of developing a product from gathering requirements to testing the software to verify those requirements. This paper presents a software engineering capstone project conducted by students at the University of Virginia s College at Wise. Their work and the methodology and tools that they used are recorded with a focus placed on the experience they have gained and additional methods which could be used to enhance the capstone experience. Keywords: Capstone Project, Software Engineering, Software Requirements, Software Design, Requirements Traceability, Project Management 1 Introduction While students pursue degrees in software engineering, they may take several courses that relate to various aspects of the software development life cycle. Courses such as requirements, design, configuration management, project management and testing are all necessary because they teach students about important software engineering concepts that they will need to use in their careers. One of the drawbacks to some of these classes is that they teach concepts in relative isolation to other aspects of software development. In reality, many of these concepts go together. For example, requirements developed in the beginning of a project are traced throughout the course of the development effort to several documents, such as the design document and the testing document. Also, errors made early on during the requirements phase can have repercussions for later phases, which can often include rework to correct the problems. These important concepts might be lost if a student takes a course in requirements and completes a requirements development project but does not need to design, implement, and test those requirements. Capstone projects allow students to connect the different phases of a software engineering development effort by working on a software project over two semesters. Students typically develop a new piece of software, so they are responsible for everything from requirements development to verifying the functionality of the software through formal test procedures. By taking a customer's high level business requirements and completing a product to satisfy those requirements, students can understand how all the different aspects of software engineering connect together. This serves as a complimentary activity to learning theory in the classroom. Often, through practice, students can gain a better grasp of the theory of software engineering rather than solely studying texts. This paper presents work done during the Fall 2012 semester for the software engineering capstone project conducted at the University of Virginia's College at Wise. The software to be developed was intended to be the official application for the university. The Office of Media Relations and Communications was the customer and they had requested a mobile application which would allow users to gain access to information about the school. Currently information about the college is readily available, but it is difficult to find particular pieces of information due to the vast amount of college departments, services, and activities. Android was chosen as a development platform because the department already had mobile phones to support this and it was thought that the Android platform would be the easiest to develop software for. The paper focuses on the development methods the students used to complete the first part of the project (through the beginning of code construction) and could be used to start a template for future software engineering capstone projects. 2 Project Management The capstone project is designed to encompass two semesters. During each of the semesters, the students have to complete different software engineering related tasks. The first semester is designed to make the students complete requirements development activities, produce a design, and to begin coding. The second semester will have the students complete their coding and then verify the software works by running a formal system test. As with any software development effort, there is need for project management activities to track and correct issues to minimize their impact on the project [6]. This is especially true since the students have a fixed schedule that does not allow for very much slack in case the project should start to fall behind. Both semesters include project management activities. The activities during the first semester included creating a schedule complete with

2 milestones, developing a risk mitigation plan, and conducting weekly status meetings. Since the capstone project is supposed to be completed within a given amount of time each semester, the students did not have much leeway in truly estimating how long tasks would take to complete. They had to work being constrained to one semester. However, in creating the schedule, they have learned that it can be a valuable tool to track program status against pre-determined milestones. A risk mitigation plan was developed by the students to think of different scenarios which could happen over the course of the project that would impede their progress. Risks were identified by team members individually and then combined together in a brainstorming session. Each team member came up with a list of risks associated with the project with an estimation based on the probability of the risk occurring and how much of an impact the risk would make on the project. The list of risks were then compiled and discussed to determine final weights associated with those risks. Risks were identified to have two main criteria, probability and impact. Probability was the chance of a risk happening based on a scale of 100. Impact was how fatal the risk could be to the project, on a scale of 10. The risk was then given a score based on the formula as shown in (1). (1) This means that a risk with 30% probability and an impact of 8 had a total score of 24. The scores were then grouped together into general categories ranging from very high to very low. The list of risks identified is presented in Figure 1. Figure 1 Identified Risks Each week, the students would meet to discuss any new risks and to recalculate the total scores of each identified risk as a means of monitoring them. Any risk with a change in total score greater than 10 would be marked and further actions discussed to manage the volatility of the risk. In addition, each type of risk had its own monitoring activities and requirements. For instance, scheduling risks were monitored through a collective schedule of each team member s availability and each member was responsible for informing the team of any changes that needed to be made to their portion of the schedule. The students also developed risk mitigation plans based on the type of risk. Continuing on the previous example, to mitigate schedule risks each team member must keep close tabs on their schedules and inform the other members of the team of changes in their schedule in a timely fashion as well as take steps to ensure flexibility in their scheduling. Status meetings were also held weekly so that students had a chance to discuss their status and any issues that were impeding their progress. Each team member was responsible for presenting a list that included what they had worked on in the past week, their plans of what to work on for the following week, and any issues they had encountered that were holding up progress. This allowed the team to learn about issues and correct them before they became a bigger problem which could greatly affect the project schedule. These items were presented to the group so that each team member was kept up to date on each part of the project. The team understood what was completed, what was being worked on, and when these were supposed to be completed, as well as what hasn't started. With this information, the team could compare the items to the schedule and figure out what needed to be changed to keep the team on track. Items are listed on a percentage complete scale from 0 to 100. This detailed the progress done to the item in order to provide more information for the team. 3 Requirements In order to develop a set of requirements for the project, the students had to perform all four phases of requirements development: elicitation, analysis, specification, and validation [1]. Rarely are all these four phases performed in a one-time linear sequence. Most of the time, the phases are performed in an iterative fashion [2]. This benefits both the software development team and the customer because rework done during the requirements development phase is less costly than rework at the later stages of the software development life cycle. The students started the requirements development phase by having a meeting with the customer to go over what they wanted from the software. At first, they only retrieved very high-level requirements. The initial requirements included having the application retrieve and display the following items: University news feed Campus directory Campus map Directions to the campus University sports feed Alumni information Campus dining information

3 The students met with the Office of Media Relations and Communications several times to elicit requirements. They then scheduled a more detailed interview with the customer in order to formulate an adequate list of requirements. The second meeting with the customer was more informative, and the students were able to start a list of requirements to review with the customer. They took those requirements and considered how they would design the system around them and their feasibility. The students also encouraged the customer to think of more requirements during the time between the second meeting and the third meeting so that they could consider all the requirements before the design phase. To capture the expected behavior of the system from a user s point of view, the students developed use cases to model the interactions between the user and the software. These use cases formed the early part of testing done in parallel with the coding done during the first semester of the capstone project. The use cases would also be used to develop unit tests for the second semester and the test document which would be used during formal system testing. The third meeting reviewed the requirements from the previous meetings and the students also retrieved new ideas and requirements that the customer had thought of since the last meeting. By encouraging the customer to think of any extra requirements early in the requirements gathering phase, the students hoped to avoid any costly additions of extra requirements in the design and coding phases. This was successful because they were able to retrieve a good comprehensive set of requirements. The fourth meeting covered finalizing requirements and reviewing any issues with them. The students and the customer discussed any issues with resources and the feasibility of specific requirements. They also unofficially finalized the list of requirements that were gathered to that point. The final meeting of the requirements gathering phase concerned the formal finalization of the requirements that had been gathered. This included reviewing the entire software requirement specification (SRS) document and noting any missing items. The SRS was based off the IEEE standard [4], and the students had tagged each requirement to provide requirements traceability for other documents to be constructed, such as the software design document and the software test document. The final meeting concluded the requirements phase and the students proceeded to the design phase. During the requirements review, the customer signed off on the requirements, so that they had an understanding that the SRS represented the scope of the project. Over the several meetings that the students had with the customer, the list of the requirements grew. The finalized requirements had all the initial requirements included plus these additional features: Social media site links Student services links Convocation center website access It was beneficial to both parties to agree to baseline the requirements so that would narrow the expectation gap between what the students were developing and what the customer was expecting. 4 Design Once the requirements had been baselined, the students began to create the software design based off the requirements. The students used the IEEE standard [5] to create the software design document (SDD). The SDD contained a requirements traceability matrix so that it was ensured that no requirement was overlooked when making the design. The system was built in three layers: the user interface, logic, and communication. As shown in Figure 2, each of these layers had several corresponding classes that would need to be implemented. Figure 2 Subsystem Packages Due to the unique architecture of the Android operating system, the user interface must be combined with some logic and communication classes. The user interface layer displays all items on screen that the user will need to control, understand, and navigate the application. This layer also holds all user interface items that the system uses. The user interface layer is also a container for the logic layer, and sends input to each of the logic layers functions as they are needed. The logic layer is what holds the methods and classes needed to perform each system action. This layer also holds the data needed to communicate with the user interface layer and the communication layer. The logic layer is also the main level of the application, since it performs the necessary functions. In order to design the interactions between the different layers, the students created sequence diagrams similar to the example shown in Figure 3. The application was designed in a layered architecture due to the need for only three levels of system performance. The user needed to perform an action, the system needed to respond and obtain the data required, which needed a communications level, and then it needed to display that data. The students chose this

4 because it fit the application's needs perfectly and works well with the way the Android OS is designed. The main tool used for the user interface design was Adobe Photoshop CS5.1. The icons for the different pages were designed so that their purpose would be easily recognized. Most icons are original designs with the exception of a few logos. The style of the icons is designed to look like frosted glass buttons which is based on current popular mobile phone applications. Photoshop allowed the students to quickly mock up what a screen would look like in the finished project without having to develop it in an Android application. Based on the functionality required for each screen to operate correctly and fulfill the requirements completely, classes were able to be developed for each screen. The home page contains icons that direct the user to the different pages. The icons are designed so that the user can quickly recognize what type of information which is displayed on the page where the button will direct them. The icons include news, calendar, directory, dining, maps, sports, Moodle, bookstore, the weather channel, and social media. The home page is shown in Figure 4. on the class diagrams that had been developed and that were included in the software design document (SDD). They had also developed a general prototype to establish flow through the application. This first prototype was intended to contain a generic user interface, but function as a final product in the flow of the application. This prototype contained placeholder buttons and icons that were linked to empty screens to ensure that the application worked properly and that each major requirement had a screen that would contain the correct information and functionality. After this prototype passed preliminary tests and was reviewed, it was saved, base lined, and a new iteration was started. This new iteration of the prototype was intended to perform basic tasks and featured the finalized user interface so that it looked and felt like the final version should. As the prototypes were developed, each time a method was changed or added, a unit test was performed to ensure that the system worked correctly and was stable. The students approached the project with the philosophy of extensively testing each method to ensure that every part of the application worked on the most basic level. Figure 3 Sequence Diagram The bottom of the home page will also contain an information and alert crawler. Text will scroll across the bottom of the screen letting the user know the important messages without having to click any icons. Most icons will direct the user to a filter page to filter out the information that is displayed on each page. The pages that will have a filter page include the news, directory, dining, maps, sports, and alumni icons. The directory, news, and sports pages will contain filters as well as a search option that will be at the top of the page. 5 Code Construction The students began the coding phase by establishing coding standards. They proceeded to code the project based Figure 4 Application Home Screen 6 Configuration Management A configuration management process was established to maintain the software and all supporting documents and information for the project. The students used Git [3], an open source tool, to manage changes to files and documentation for the project. They also devised a change control process, as shown in Figure 5, in order to evaluate change requests, whether they came from the client or a team member. Change

5 requests were evaluated by the team, which consisted of discussing alternatives to the change and whether or not it was necessary. If deemed necessary and the best way to make the change, the change was implemented into the system. From there, the change was validated to ensure it was the right way to correct or improve the previous implementation. If the change was validated it would then be incorporated into the system. Change management was essential in deciding what the schedule could handle as new requirements were added to the system. Early on the decision was made to incorporate a reporting and analysis section to the system, and through the change management process the students were able to evaluate the functionalities worth and determine what it provided the system and customer. 9 References [1] Introduction to Software Engineering Body of Knowledge, Last accessed on March 8, [2] Karl Wiegers, Software Requirements 2 nd Edition, Microsoft Press, 2009 [3] Git, Last accessed on March 8, 2013 [4] IEEE Std , IEEE Recommended Practice for Software Requirements Specifications, IEEE, [5] IEEE Std , IEEE Recommended Practice for Software Design Descriptions, IEEE, [6] Introduction to the Software Engineering Body of Knowledge, Last accessed on March 8, Conclusions Figure 5 Change Control Process This paper presented the first half of a senior capstone project that focused primarily on gathering requirements and producing a suitable design. The code construction commenced in the first semester of the project, but will not be completed until the following semester. The students gained a great deal of experience by having to develop a product from the beginning by using the concepts they have learned in taking software engineering courses. Having a consistent process in place benefited the students by informing them what was expected. It would be beneficial for a university teaching software engineering to have a defined process and document templates that capstone projects could use. This could be similar to an organization developing its own software process to make it more consistent between various projects in the organization. The process may then be modified depending on the project type. 8 Acknowledgements The authors would like to express a sincere appreciation to The Office of Media Relations and Communications at the University of Virginia s College at Wise for support of the capstone project presented in this paper.