Paper Review: Software Development Processes for Mobile Systems

Hi again!

This is a departure from my usual weekly post to present to you a paper that is related to Software Engineering, and Agile Development specifically. This paper is

Software Development Processes for Mobile Systems: Software Development Processes for Mobile Systems
link: http://www.inf.unibz.it/~gsucci/publications/full%20text/full%20text/MOBS13.pdf

This paper focuses on determining whether Agile development practices are suited to Mobile Software development, and additionally provides many examples of how Mobile programming has evolved.

Before delving into some of the point presented in the paper, I would like to say that the research done in this paper, is presented sparsely. The information given is useful for those interested in mobile development from a research perspective. It can also be interesting from a mobile developer's perspective, in that one can analyze their own methodologies and frameworks and see how they line up with what this paper presents. I would recommend this as a general overview, but in terms of deeper data, I think this paper falls short.

There are five major points presented in the paper, which I will briefly summarize below:
I. Introduction
This section presents the problem and the researchers' desire and plan of course. In addition, the authors present information regarding the sources of interest that will be presented later in the paper. This basically gives the reader the knowledge that there are different types of Agile practices with regard to Mobile development, and that these different practices have at least in one instance made their framework public in the form of other research published. The authors attempt to  "introduce discussion in four thematic areas: (a) suitability of Agile methods to fit the needs of the mobile business environment; (b) suitability of Agile methods to fit the needs of the mobile operational environment; (c) adoption of the proposed Agile frameworks and evidence about their real use, and (d) the rise of new conditions that challenge some of the premises upon which the proposed methodologies were designed." I believe that they do touch on these points within.

II. Mobile Software Development
I found this section particularly interesting as it lays out some of the constraints of mobile development such as, "(availability, bandwidth variability), mobility issues (autonomy, location-based services), the variety of platforms and technologies, the limited capabilities of terminal devices (low power supplies, small-sized user interfaces), and time-to-market requirements." These issues keep mobile development in flux, and as this type of software engineering is a relatively new process, new technologies are continuously emerging making it even more difficult to assess the frameworks of development practices that are currently in place. To reinforce the notion, this is more so even than with traditional software development due to the new technologies and different constraints that present themselves as mobile devices continue to change.


III. Agile Software Development Processes for Mobile Applications
This is what I would consider the main section of this paper in terms of information. This section presents the methodologies of 5 specific types of Agile-like practices for mobile application. These are: Mobile-D,  MASAM, Hybrid Methodology, Scrum, and Scrum Lean Sigma Six (SLeSS). Unfortunately, while many of these methodologies have been reported to be in practice, only one, Mobile-D has any evidence of showing itself in use. Those that have used Mobile-D have case studies, and reports to show how and what they do, which allowed the researchers here to present some decent evidence in the next section. Each method offers main points of agile development while adding their own flavor. Some of the most noted of which are specific phases required during development to include test-driven development, continuous integration and pair programming.


IV. Discussion: Accomplishment, Evidence, and Evolution
 This section provides three main questions, Are Agile development practices the best fit to mobile, do they address the needs of mobile's fast-paced release cycle, and is there enough evidence. As these questions are addressed, the resulting conclusion is that it is hard to prove. The evidence is simply not there. Of the five different methods given, only one, Mobile-D, has more than 5 works citing application, at 17 reports citing 16 case studies. I would consider this to be severely lacking in order to come to a complete conclusion.
 
V. Future Work and Concluding Remarks
 What this leads us to is that mobile is like traditional software development continuously changing, and requires the developers to adhere to new rules, adopt new technologies, and find what suits their particular environment the best. Mobile development is growing in size as are the apps that are produced, and there simply is not enough evidence to show whether or not Agile currently suits this practice.

The authors write, "

To provide a final answer to our research question, there is a clear need of conducting evidence-based research that unveils what mobile development practices are actually used, to have a factual picture on how development teams are conducting and managing mobile software projects."

So there you have it, we need more research on the subject, and this paper clearly shows that this is currently not the case. Further research would likely improve mobile development by offering conclusive evidence of what works and what does not.

Cheers!

Week 14 - IDB3

Hey,

It's Easter Sunday, and it's the day before the second to last week of classes. I know I should be talking more about the previous week, and I will, but I thought it might be nice to put this post into some temporal context. I'd like to detail here an overview of the process one specific feature that my team worked on to give a bit of insight of working on this project. If you are interested in learning more about the process, I believe we will be posting our technical report on our site in the future. Check it out -> http://blooming-shelf-7492.herokuapp.com/

This past Thursday, the third and final iteration of our latest project, SBIDB, was turned in. The turnin for this project gave us the first major Heroku issue that we have had thus far, and therefore we were unable to turn it in as a working project on time. My team, thank them mucho, met up on Friday to debug what the issue was. As it turns out, we were able to turn in our project from our last commit on the due date and still get graded from that point due to an obvious bug in our Heroku deployment. After all of the commits and headbanging, it is really confusing as to why the build did not work out from the start, but I am very glad that it is up and running and looking as we hoped it would. 

For this iteration, we were to implement a search functionality to our site to search through the contents of our database, and return contextualized relevant information via the search. At first, we attempted to use an add-on to Heroku, SearchBox Elasticsearch. To use this with Django, you use a modular search package called Haystack. Well, long story short, we had a bear of a time trying to get these to work together, with our code, and deploy correctly on Heroku, and in the end we scrapped it. We searched for another method of implementing this beyond using the ORM of Django for ourselves. 

We found another package called django-watson to search, and found this to work very simply out of the box for a simple search. Upon testing this search, however, we realized that this module, while its documentation described some functionality that we desired, did not seem to offer what we were looking for in terms of searching for ForeignKey relations in our Django models, and therefore our SQL database. This, along with creating search results that display multi-word OR results gave us some added trouble when needing to fulfill our requirements and get this project turned in. So, we modified the search to offer us both single results of each word searched as well as the built-in ANDed results from django-watson.

To take this part of the story back to the beginning, we also added a highlight function to our search to highlight the search terms on the search results page using a custom Django template filter. When implementing this functionality, we originally placed the code within the django-watson package, and realized that later, this would probably cause some issues with Heroku when rebuilding the virtual environment, so we moved the code into its own pseudo-package. Well, when we were at the final point of realizing that we had a problem with our turnin, we thought that this move, and implementation completely, is what caused our errors on the server. This last ditch effort was very frustrating as a team, and left many of us feeling pretty poorly about our final product. But at this point, again, I think this finally turned out to be just about exactly what we expected. 

All right, I'm out of here for this week. My team has a presentation to hammer out, and a test to start studying for.

See ya next time,

Sophie

Week 13 - A Good Week

Hey again,

We are back on an off week this week. By that I mean that there is nothing due or overly pressing this week to be worried about. Now that we have been working on the IDB main project, we have had a biweekly stress meter that runs up and down depending on when the next iteration is due.

So this past week, my team and I took some time to go over the new requirements for this project and try and lay it out a bit more structured in terms of front-end/back-end/mixed teams to get some work done on the project while we all have such different schedules. I think this was a good way to start, though checking in over the course of the week has been less than informative. Nonetheless, I think we are doing ok on time. Of course, this project completes this coming Thursday, so I can expect that as that day grows closer, we will be ramping up with work.

As far as the class goes, this past week we went over some more SQL stuff, and some design patterns. We took a look at the singleton pattern the previous Friday and on Monday we went over Reflection in Java. Still waiting to get to the Python version of this though.

Wednesday we had a guest speaker/lecture about working in the industry. This was probably one of the best talks I have heard in a class since I have been in school here. The main reason for this is that Trung Vu, from The Zebra, went through his slides very quickly and then had a lengthy Q&A section, which turned out to be really informative and helpful. He had worked at three different sized and types of companies since graduating four years previously, which I feel shed some really good light on to what could be expected shortly after graduation. I especially liked the tips and hints he gave about prepping for interviews as well as how to feel about working and timing and estimation. It made the class feel really relevant, and put the Django stuff that we have been working on in perspective. Overall it was a pretty good week.

But, now I have some other things to do.

~Sophie

Week 12 - Project 4 aka IDB v2

Hi again,

The 12th week of school is over!!! Extreme, though short lived joy must be expressed for the end of that week. I had two projects due and an exam this past week, and then an exam tomorrow that I should still be studying for right now. All of these deadlines made for a crazy busy week, not to mention the perhaps overly lax approach my group and I took on this second iteration of (SB)IDB.

I’ll be able to take a breath after tomorrow, only to begin working on the last part of this project right afterward. One good thing about this last project is that it’s deadline is two weeks before the end of classes. So, it will not coincide with deadlines for other classes, or any other tests really, which for me is quite nice.

I don’t really have much to talk about this week because much of the work that was done this week was so close in context to what happened last week, but we do have a requirement to meet so, the blog must go on.

One thing you may note if you read any of the other students’ blogs from this semester is that the deadline for this project was extended by a day, due to a misunderstanding/oversight on the spec. The spec for this project was therefore updated with a clear representation of what was due at a late hour, and most of us realized at that point that we had quite a bit of work ahead of us. This last adjustment was about the API. The last iteration of the project required that we have documentation for an API using apiary.io. One cool thing about Apiary is that it allows you to set up the API and run your tests against a mock server. One thing that is not cool about this, is that it is not a full implementation of the API for your app. So, you have this API documented, but have to then implement it using another method, and need to run your tests against the real API, which could lead to some inconsistencies that you later find need adjusted. In the end it worked out, but I give much credit for the API to one guy in our group, and would like to say thanks for that, Yoan! Sitting in the lab with him and writing tests against the API was really helpful in gaining a greater understanding of what was actually going on.

My last thought for this week, “Hope the grades go well this time.”

Until next week,

Sophie

Week 10 - IDB1 is Done

Hello again,

So, last time I wrote a bit about the project that was due on Thursday of this past week, and as you may have noticed, I was feeling pretty good about it. Now the project has been turned in, and I am feeling really good about the product we submitted. Our group met up quite a bit throughout this week to add to, move around, and decide on the generalities of the project while making sure to understand and meet the requirements that were laid out by Dr. Downing. I also feel like we got a relatively large chunk of work done for the amount of time that was spent working. I shared the project with some friends to show some of what my school work is like and I think they were fairly impressed.

My group chatted for a few after class on Friday so we have a reasonably good idea of where we need to start to tackle part 2 of this project. We changed some ideas on our Django model structure during the course of the project and I think we are still needing to really solidify this before moving on. In addition, while I think we are all feeling like our site is looking damn snazzy, we talked about getting some basic design decisions going for the look and feel and will want to get that going as well before/while we are setting up our templates to pull in data from our database. From the discussions in class this week and the end of the last week, I have an idea that Dr. Downing will want us to really focus on getting our databases working well with our apps and possibly get some thought down for refactoring.

This week was the first week we were assigned to read from the Refactoring book, and there was a quiz on it on Friday. I did not give myself time to read from it before class, so my quiz grade was a whopping 1 point for putting my name down, nice. This week was also the week following Spring Break, and I have to say that I am glad that the second iteration of this project has not yet been formally posted. I feel like I have not had a break since the week before Spring Break and am happy to have this time to relax, even if it is only for a couple of hours. I had a project meetup today for my computer graphics class, so I did not get the entire day off, but it still feels quite nice.

Speaking of relaxation, I think I may have a few more moments of it before getting back to the grind.

I'll be back!

~Sophie

Week 3 - Project 1 is Done

Hi again,

So, Project 1 was due on Thursday. This project was one of the problems from Sphere Online Judge, spoj.com. This online oracle takes submissions for solutions to the huge project set they have, and "grades" your submission based on its ability to solve the problem as well as timing the solution. For the purposes of this project we wrote code in Python, and had to implement a cache in order to speed up our solution in addition to being one of the base requirements for getting a non-zero grade.

Dr. Downing gave us examples of the different types of caches available for us to use, and I found that with some tweaking and changing of my code, the fastest iteration that submitted was one with the simplest solution, a lazy cache. I later realized that had I not used recursion I probably could have sped up my code, but I did not go back to adjust it. I decided this time that the solution I turned in was good enough. And, because I know that the semester will ramp up pretty quickly with multiple deadlines and exams in the same week, I thought it would be better to use any extra time I had to be sure to be caught up in my classes for now.

Then, I was reminded that the career fair was on the same day that the project was due, and felt really glad that I got my project ready to be turned in ahead of time. The career fair was exhausting. I spent a lot of time talking to a bunch of different people about some of my past projects, what I like to do, why I would like to work for their company, or be a good fit, all while standing for hours, and feeling overly hot in that building. Even though the conditions can be overwhelming, I did enjoy talking with all of the recruiters and engineers, and know it was well worth it. I have some interviews coming up, and those require some study time too.

The next day in class we talked about Z scores, standard deviation and a root-mean-square (RMSE) problem. We went through some of the code for solving this problem in class, and we will be using this information for our next project, Netflix, which we will be learning about this coming week. I'm looking forward to hearing the specs on this one.

Reading this blog post over, it reads a bit disjointed to me, and I feel like I must be extra tired right now. The weather has been fluctuating between 30 degree ranges nearly every two days, and my allergies have been kicking my butt. I have been trying to keep from getting a cold, and stress is not a good agent for keeping the immune system high. So, I think I had better rest up, and stay on top of my studying.

I'll be back to write some more next week.

~Sophie

Week 2 - A One Day Week

Hey again,

Well the week was, as usual, a full 7 days, but due to unforeseen weather changes this class only met once. On Wednesday the proctor for the class, Alex Coomans, gave a lecture on getting started with git. We had a quiz at the start of class over the reading, which I found particularly straight forward having already read the two articles assigned to us in previous classes. Then with little time to spare at the end of the class we went over some of the Collatz changes that Dr. Downing made. He changed some of the starter source code for us from Python 2.7 to Python 3.

Because the class time this week was so short, there is not much to report on for the actual class experience. I think this may have put us back on schedule a bit as far as understanding how to improve the performance of our Collatz program. Our original schedule had us discussing caches on Friday, the day the school was closed due to inclement weather.

Outside of this, we have a discussion board for the class, Piazza, which gives us a forum to ask each other questions over the material, share what we know, and get helpful input from the TAs and Downing himself. He has this week been very forthcoming with his advice to us, imploring us to post on Piazza, and attend the weekly study sessions. I have already found a post there from a classmate about a feature of Python that is pretty cool.

There are two scheduled study sessions a week on Tuesday and Wednesday that we can attend in the evening to study for the class and help out our classmates with anything they may be uneasy on. The sessions are run by the TAs and proctor, all of whom have experience with the class structure and can be helpful with both the class assignments, as well as any general questions. And, this is time outside of their regular office hours. Sadly, however, I have not attended any of the sessions thus far. I have been easing into my new school/work/life schedule slowly, and I hope to be able to schedule myself to get to at least one a week. I know that these sessions can be immensely helpful with studying for the exams in the class, of which we have two coming up, and no formal final!

Despite the short week, I had enough to share about generalities of the class, and how they affect me, in order to reach our 350 word minimum requirement for the blog posts. And just in case I didn't make this explicit in the last post, this is an extra credit assignment. We are to write a weekly blog post to you the audience, who is hopefully interested in taking the class and wants some personal insight on it. I personally enjoy having this as an assignment as I think that it will help me to improve my writing skills, while also giving me some perspective on how I am doing in the class. We have two additional extra credit opportunities in the class, which I may expound upon later.

Until next week...

~Sophie

Week 1 - Course Description and Introduction to Project 1

Hi,

Here is a little recap of my first week of this class. On the first day we went over the course description and some of the details of turning assignments in, a daily quiz structure, and what books we will need for this class. Professor Downing said that this class has a writing flag, which everyone in CS needs,  and I believe is one reason that many students will opt to take this class. In order to fulfill this writing flag we have to write a 3000 word report! Wow. Luckily the professor said that we will be breaking this up, so it will not seem like a huge task.

Over the rest of the week we moved on to talking a bit about the Python programming language, and then specifically about the first assignment, which is done solo by each student. I found it quite helpful that Downing gave us pretty full Java code examples and then compared them to the same bits of code using Python, which is the main programming language in this course. I have not used much Python before, so getting started with a new language while getting started with the first project adds a bit of work, and the comparisons with a familiar language seem to make the transition easier. In addition to Python in this class we will be using many different languages and frameworks in order to get some experience with full stack programming. This should help to prepare us to get a job, and I like the sound of that!

On Friday we had our first quiz, which surprisingly took me by surprise with its questions. I thought I had a handle on it, but I missed a couple of simple details, and that is what good programming is all about! Happily, I am not worried about it this early into the semester. I have been having some severe allergy attacks lately due to the record pollen highs and overly long "Cedar Fever" season here, and feel like once my head clears up I will be able to gain my focus during quiz time.

I'll let you know how this next week goes!

~Sophie