Ayoub 1

Alan Ayoub
CST 438 Software Engineering
David Wisneski
12/16/2016

Our group has decided to improve upon the programming assignments in

Assignment #1,4,6. The main objective of our project is to add features to the program that

currently do not exist. Some of the features include showing the letter guessed in the user

interface, adding multiplayer options, incorporating a solver, adding CSS, and determine

the level of difficulty to guess a word. The reason why we chose this project is to ensure

that we follow the agile process and give ourselves manageable tasks that we can work on

and improve upon in a future sprint. We have a short amount of time to accomplish our

goals, so we thought this would be a great way to approach our project.

Code quality is the estimation of how useful and maintainable the code is. If the code

is not very useful the next day, that means it is low quality. High quality code can be used

across many different products and can also be improved upon like open source. If a

program is 200 lines of code and it accomplish the same exact product in 25 lines of code,

its better to simplify the program and not repeat code. Code must also be well documented

with comments so that anyone can easily understand the purpose of the code. The speed of

the program is also important and we want to make sure that we write code with good

performance in mind. We want to make sure that all variables have meaning and we are

using tabs and spaces properly. To ensure that our team delivered quality code, we have all

communicated with each other and asked for feedback. We remain open to suggestions to

improve code and we ask for help if we are unsure about how to implement a feature.

Team velocity is the number that tells us how productive our team is. We can

determine the team velocity by understanding the productivity trend of our team. Our team
 Ayoub 2

consists of four team members. Three of us have been actively communicating and figuring

out what tasks we will agree to do and who will take on certain tasks. Once we decide on

the tasks, we will give each task a point rating from one to eight depending on how easy or

difficult the task is. Based on our productivity week to week, we earn a score based on the

point system. After about three different iterations, we can determine the team velocity

based on the points that were earned in each iteration. For team velocity, we will use the

average score and that score can serve as a predictor for the amount of workload that can

be completed in a future iteration. In our case, we did not really get into a good rhythm to

develop or team velocity. It is still early and we need more iterations to determine a more

accurate team velocity. Team velocity is a great indicator of the work that is likely to be

completed in future iterations, I would use this measure in future projects.

If we were to start this project all over again, I would recommend that we have a

mandatory meeting and meet with our group on day one to discuss the projects direction

and to assign tasks. Our group has been group, however, we were too generous and relaxed

in an effort to include everyone and the one person that we have been waiting for has

disappeared. Also, after our group meeting we learned that we needed to stress more

importance on testing. Next time around, I would do a better job of emphasizing the testing

phase.

Initially, our team defined the scope of the project through email. After about a

week, we began to have face to face meetings and thats where the real productivity began.

There seemed to be more accountability and urgency for how tasks were handled after we

concluded our meetings. We have used zoom, google hangouts, google group chat, and we

have screen shared often. Overall, our communication has been excellent.
 Ayoub 3

Our team meets face to face through zoom or google hangouts every three days. We

also remain in contact through hangouts almost everyday.

Initially, there were problems with other group members. As I mentioned earlier,

one group member disappeared and we collectively wanted to give him an opportunity to

come around. At some point, it didnt make sense to wait around and we all agreed to move

on without him with the possibility of him joining us and taking on tasks created in pivotal

tracker. Also, I am very new to github and I ran into some issues. Luckily, one of my team

members is very familiar with github. This team member spent valuable time with me

making sure I had to the correct settings plugged in. In the end, my issue was resolved

because of the commitment of my team member.

The requirements of our project changed as we realized that there were crucial

tasks that needed to be added. We added the testing cases tasks and databases task at

about the 50% mark. It seems like the agile process has been great for us. We could have

used a waterfall process too or a combination of both agile and the waterfall process. If I

had to choose, I would say that the agile process has been a great fit for our team. We seem

to have found a communication and production style that fits agile well.

Formal process (Formal Methods) are usually used when our program becomes

more complex. The formal process are mathematical based methods that prove the

correctness of a system. Formal methods begin with formal specification and are then

followed with formal verification. In our case, our program was not complex and adding a

formal process would actually be counterproductive since our product is too simple. If we

were developing a complex program, formal methods would be useful.

 Ayoub 4

In the first couple of weeks, we did not address nonfunctional requirements. At the

50% mark, we realized that we needed to address performance, reliability, scalability, and

ease of use. At this point, we have not completed the project so its difficult to determine if

our nonfunctional requirements were met.

Instead of having a separate documentation, we have decided that its best to

thoroughly comment our code. This way, if a new programmer joins our team, they will be

able to see the code and the documentation in one place. This ensures that our

documentation is current and reliable.

At this point, we have not have not run into a need to refactor our code.

Please see the following diagrams:

 Ayoub 5
 Ayoub 6