CSCI 136
Fundamentals of Computer Science II
Spring 2018

Montana Tech of The University of Montana
Computer Science & Software Engineering



Lab 1 - Software Development Process

Lab 1 - Software Development Process

We talked about the software development life cycle in class last semester, and we interactively (and informally) went through the process on the board, but now you get a chance to work in teams and do it yourselves. We will divide up into teams of (around) 4 students. Each team will be given a different problem. First of all, the team will work on the problem and come up with a list of requirements. After a set amount of time, each team will pass their set of requirements and the problem on to another team and will receive a different problem and requirements. From the requirements, each team is to design the solution, again, given a set amount of time. Once done, they will pass the problem, requirements and design on to the next team, and will receive a different problem with requirements and design from another team. Each team will then implement (code) from the previous team's design. By the end of the lab, we should have at least a prototype of a solution for each of the problems given in class.

The problem descriptions that will be handed out to teams are going to have ambiguities in them. You will need to, to the best of your ability, decide what needs to be done. If you have to make any assumptions, identify these in the work you turn in and pass on to other teams.

You will want to be careful in each step so that what you pass on to another team is complete and detailed enough that they can use it for the next step. But you don't want to address too many aspects of the system and make it too complex- it should be small enough that it can be implemented in lab. Yes, I know, this is hard!

Don't stress about getting this perfectly correct. What I really want to see from each of you is that you go through the process and do your best. This is hard because 1) you haven't done it before, 2) you are working in teams, and 3) you will be doing work from another team's documentation. I will be circulating around the room to help as you have questions.


Part 1: Requirements Analysis A software requirement is either functional or non-functional. A functional requirement is one that the software must eventually implement - that is, the code will implement that logic. A non-functional requirement is one that the software must conform to. For example, the software might be required to produce an answer within a given time frame. This is a non-functional requirement because it is not something implemented by the logic. An example of a functional requirement might be "The program must take two numeric inputs and return the sum of those inputs."

Requirements should specify what is input to the system, what happens to that input, and what is output from the system. Any functionality the software must have should be on the list of requirements. You need to be as specific as possible. Good requirements are: You can use Microsoft Word or a text editor to write up your requirements. Make sure that all the team member names are on the document. When we are done with this part, you will submit this to Moodle (only once, I don't need a copy for each team member), and then email it to the next team.

Part 2: Design Given a list of requirements one can then design the eventual software system. What will the classes be? (Remember how we identified potential classes based on the nouns in the problem description?) What methods are needed in the classes? (Again, remember we looked at the verbs and what needed to be accomplished.) Can we identify major data items? Inputs and outputs to each part? The minimum output of the design should be an API that lists the required public methods for each identified class. An example of an API is shown below. It specifies the class and the public methods associated with the class.

Example: The Avatar data type must implement the following API:
public class Avatar
----------------------------------------------------------------------------------------
            Avatar(int x, int y)      // Create a new Avatar at index position (x,y)
        int getX()                    // Get the current x-position of the Avatar
        int getY()                    // Get the current y-position of the Avatar
       void setLocation(int x, int y) // Update the position of the Avatar to index (x,y)
     double getTorchRadius()          // Get the current torch radius   
       void increaseTorch()           // Increase torch radius by 0.5
       void decreaseTorch()           // Decrease torch radius by 0.5, minimum is 2.0
       void draw()                    // Draw at the current position
Again you can use Microsoft Word or a text editor to write up your design. All the names of team members should be on there and the design should be submitted to Moodle (once for each team) and emailed to the next team in line.


Part 3 Implementation Now you get to have some fun. Try to implement the software from the requirements and design that were passed on to you. Likely there will be ambiguities here also, and you will need to use your judgement. Document any assumptions or changes you had to make in comments in your code. We will only work on this a set amount of time, so that everyone is done with the lab before the end of class. Even though the due date on this is not listed until next week, I don't want you to have to work on it later. It's going to be a bit of a challenge to program as a group, but do your best to make sure everyone has input.

Your code should be submitted to Moodle, again, with all team member names on each source code file, and only one copy should be submitted.


Grading
Grade ItemPoints PossiblePoints Earned
Requirements 10
Design 10
Implementation 10

Submission. Submit your documents (requirements and design) and your program via Moodle. Be sure each submitted program file has the required header with all of your team members' names and a description of the program. All your methods must be commented using javadoc. Also, be sure to submit the .java source files and not the .class files!



Page last updated: December 27, 2018