CPSC_544_HWK_1_FINAL (1)

THE EMPIRE - INSERTION SORT

ALGORITHM

CPSC 544 – Advance Software Process

September 28, 2016

Fall 2016 – Professor Jo

Levi Martin ([email protected])Tom Wang ([email protected])

Tou Moua ([email protected])Ram Anudeep Kuchibhotla ([email protected])

Nithin Reddy Gajjala ([email protected])Naga Malladi ([email protected])

Kapardhi Chittella ([email protected])

CONTENTS1. Revision History............................................................................................................................42. Process Defined for Project...........................................................................................................5

2.1 Process Definition..............................................................................................................................5

2.2 Design................................................................................................................................................6

2.3 Development.....................................................................................................................................7

2.4 Maintenance......................................................................................................................................9

3. Definition of Work-Products, Roles, & Practices..........................................................................113.1. Roles:..............................................................................................................................................11

3.2. Work-Products:...............................................................................................................................12

3.3. Practices....................................................................................................................................12

4. Pre-Game: Planning & Staging....................................................................................................134.1. Vision..............................................................................................................................................14

5. Vision.........................................................................................................................................156. Requirements.............................................................................................................................16

6.1. Functional Requirements:...............................................................................................................16

6.2. Non-Functional Requirements:.......................................................................................................16

7. User Stories for Planning............................................................................................................188. Product Backlogs & Estimates.....................................................................................................199. Architectural Spike.....................................................................................................................2110. Release Planning.....................................................................................................................2111. Technology Preparation..........................................................................................................2312. Development..........................................................................................................................24

12.1. Sprint 1.........................................................................................................................................24

12.1.1. User Stories............................................................................................................................24

12.1.3. Managing...............................................................................................................................25

12.1.4. Design....................................................................................................................................26

12.1.5. Development.........................................................................................................................27

12.1.6 Testing....................................................................................................................................32

12.1.7. Daily Scrum Meeting..............................................................................................................32

12.1.8. BurnUp Chart Sprint 1............................................................................................................32

12.1.9. Sprint 1 Review......................................................................................................................33

12.2. Sprint 2.........................................................................................................................................34

1

12.2.1. User Stories............................................................................................................................34

12.2.2. Iteration Planning..................................................................................................................34

12.2.3. Managing...............................................................................................................................34

12.2.4. Design....................................................................................................................................34

12.2.5. Development.........................................................................................................................35

12.2.6. Testing...................................................................................................................................36

12.2.7. Burnup Chart Sprint 2............................................................................................................37

12.2.8. Sprint 2 Review......................................................................................................................38

12.3. Sprint 3......................................................................................................................................38

12.3.1. User stories........................................................................................................................38

12.3.2. Iteration planning..............................................................................................................38

12.3.3. Managing...........................................................................................................................39

12.3.4. Design................................................................................................................................39

12.3.5. Development.....................................................................................................................40

12.3.6. Testing...............................................................................................................................41

12.3.7. Burnup chart sprint 3.........................................................................................................42

13. Release...................................................................................................................................4214. Other Activities.......................................................................................................................43

14.1. Estimation.....................................................................................................................................43

14.2. Project Planning............................................................................................................................44

14.3. Project Monitoring & Control....................................................................................................44

14.4. Quality Assurance......................................................................................................................46

14.5. Configuration Management.......................................................................................................46

14.6. Risk Management......................................................................................................................47

14.7. Testing.......................................................................................................................................48

15. Lessons Learned......................................................................................................................4915.1. Levi Martin....................................................................................................................................49

15.2. Ram Anudeep Kuchibhotla...........................................................................................................50

15.3. Tom Wang.................................................................................................................................51

15.4. Naga Malladi..............................................................................................................................51

2

15.5. Tou Moua..................................................................................................................................52

15.6. Group Lessons...........................................................................................................................52

16. References..............................................................................................................................5317. Team Charter..........................................................................................................................5318. Team Evaluation.....................................................................................................................59

3

1. REVISION HISTORYName Date Reason VersionTou M. 9.8.2016 Formation of Group/Paper v0.1Tou M. 9.12.2016 Update to planning & staging section v0.2Levi Martin 9.18.2016 Work Product Updates v0.3Levi Martin 9.18.2016 Practices v0.4

Ram Anudeep Kuchibhotla 9.19.2016 Updated Pre-game i.e. Planning and Staging.

v0.5

Tou M. 9.20.2016 Design and Roles update v0.6Ram Anudeep Kuchibhotla 9.21.2016 Pre-game Planning & Staging. v0.7

Naga Malladi 9.19.2016 Iterations to Release v0.8Ram Anudeep Kuchibhotla

9.22.2016 Functional requirements v0.9

Naga Malladi 9.22.2016 Non-Functional requirements v0.10Tou Moua 9.22.2016 Design for iteration 1 and screenshot

for end of iteration 1v0.11

Ram Anudeep Kuchibhotla

9.25.2016 Add Quality Assurance or other activities

v0.12

Tou Moua 9.26.2016 Add configuration management for other activities

v0.13

Levi Martin 9.26.2016 Development Iteration 1 v0.14

Levi Martin 9.26.2016 Release Planning v0.15Ram Anudeep Kuchibhotla

9.26.2016 Added lessons learned v0.16

Levi Martin 9.26.2016 Estimation v0.17Levi Martin 9.26.2016 Development All 3 Iterations v0.18Tom Wang 9.27.2016 Lesson learned, development in

sprint iteration 3 and project planning in other activities.

v0.19

Tou Moua 9.27.2016 Update to release planning v0.20Naga Malladi 9.27.2016 Acceptance tests v0.21Tou Moua 9.27.2016 Include screenshot for design in

sprint 2 & 3v0.22

Levi Martin 9.27.2016 Added and Formatted Final Draft v0.23Tou Moua 9.28.2016 Additional detail to testing activities V0.24Tou Moua 9.28.2016 Final Version Baseline V1.0

4

2. PROCESS DEFINED FOR PROJECT 2.1 Process DefinitionGeneral Definition: A process is defined as a step-by-step path that enables us to make the best possible high quality software compatible to SCRUM and XP practices.

Project specific Definition: A process is a means in which the application development moves forward following the best practices of SCRUM and XP in order to meet the customer requirements

and deliberately accepting changes during the development of the software.

2.1.1 PRE-GAME2.1.1.1.Planning

In the planning phase, the scrum team requires to collect ample information as possible regarding the project and start building the software. Generally, planning phase helps a team in

envisioning the product and creating a path in order to reach the customer’s expectations. Planning helps in laying the budget and allocating the resources that will be used during the development of

the software product. A plan helps a team to follow a schedule formatted in order to meet the deadline and the requirements of the customer.

2.1.1.1.1. Activities

2.1.1.1.1.1. Vision

Vision is a clear plan of what a scrum team will achieve in phases while developing the software or a product.

2.1.1.1.1.2. Allocate Resources

A resource can be a stock, money, supplies and staff. Proper allocation of the resources will result in a timely completion of the project and the functionality is effective.

2.1.1.1.1.3. Monetary estimation

Allocation of financial resources is important. Proper allocation of funds to a project will ensure project’s success. Estimation includes knowing the necessity of components needed.

2.1.1.1.1.4. Creating Product backlog

Product backlog is the documentation of the customer’s requirements. Product backlog assists a team in identifying the work needed to perform in order to develop a software product.

Generally, a sprint backlog consists of the following:

5

a. Features.

b. Bugs.c. Technical work

d. Knowledge acquisition. e. Generate a Quality plan

1. A quality plan is a documentation which lay down various standards, practices, specifications and the activities relevant to the product. It is performed in order to

maintain the quality of the product.

2.1.1.1.1.5. Risk plan

Sometimes, things don’t happen as planned in a project. So, it is important to have a risk log

and an action plan for a project. Risk management strategies let us identify projects strengths, faults, chances of occurrence, impact of risk and suitable action required. Risk management plan

allows a team to take necessary actions when confronted with unexpected events. This keeps the team motivated and the project progresses as planned.

2.1.1.1.1.6. Evaluating plan

It is a good practice in evaluating a plan as we may have missed out on some of the important considerations which may be very important for the success of the project.

2.1.2STAGINGStaging helps us in recognizing more requirements compared to the planning phase. After

collecting the necessary requirements, we will prioritize for the first iteration. The primary

purpose of the staging phase is to simulate the product development environment.

2.1.2.1. Activities2.1.2.1.1. Planning

Planning in the staging phase checks the overlooked requirements.

2.1.2.1.2. Prototyping

Prototyping involves creating a preliminary model of the product, which is being built.

2.2 Design In order to begin development, it is necessary for there to be a phase focused primarily on

design. Although, this could be handled during development, it should be completed prior to development to represent the equivalence of the exploration phase in XP. The importance of this

step is to allow for the building of the CRC cards and also provide the prototype for development. Some of the activities involved in this process are prototyping, such as sketches or low/high fidelity

6

mock-ups, and creating CRC cards. The design will aid development in providing a high-level and

skeleton of the final product. One thing to note is that the design is not finalized and is meant to provide a guide with the understanding that the design may change due to changing requirements

and adapting to changing technologies.

2.3 DevelopmentWe define XP development as the key to creating higher quality software in reduced amounts of

time with respect to older methodologies. We also developed under the XP / Agile approach for

harnessing the benefits of the XP mentality. With also integrating XP into our agile development we garnered even more rapid development times with increases in output as well as fewer blockage

issues. Finally, for development definition purposes we want to focus on the improvements made to

allowing all employees to play some kind of role in the development process because getting confirmation by all team members will bring about the ultimate efficiencies as well as improvement

available to the XP / Agile development methodology. The definition of our XP planning consist of drawing out our roadmap in each structured phase

of the XP planning environment. We next need to add the framework laid out in the scrum XP methodologies. We also need to include the updates that are applicable for any possible changes

within the XP development roadmap currently defined plan’s structure, as the earlier defined. We also need not to lose focus on what is also needed with respect to the three sprint intervals

to update the plan that we have originally laid out for the products release at every sprint interval discussed. Some of the main attributes to be cognitive of our estimating and prioritizing with the

product backlogs with the team point system that allows for all participants in the scrum team to use their experience in executing the aforementioned prioritization.

Release is an important phase of the agile process. The intention of following agile process is to make sure that we have continuous delivery to the customer and before we release the product, the

QA team and the testing team have to make sure that we deliver a product that is of high quality and has no errors or bugs. There are multiple activities involved in the release. They are:

1. Documentation of the product2. Implementation and Training

3. Marketing

Depending on the type of product developed, it is always a good practice to document the product for future references and easy understanding to the client. Documentation is also done to

make sure that software that is developed is understandable to the future employees. Implementation and Training is the next important phase of the release cycle. The product when

developed and is ready for release, implementation in the client's environment is very essential and

7

the consultants try to make sure through trainings to the employees in the client's side are made to

understand the working of the product. Various formats are followed in the trainings such as videos, practical trainings and information sessions

Marketing is an important aspect especially in the product based industry. When a company delivers a product to the market the consultants and the marketing team makes sure that customers

are well aware of the products delivery to the market.The release of a product is based on the iterations. This can be categorized into two sections:

1. Release Planning2. Iterations Planning

In Iteration Planning we have multiple tasks that are to be taken into consideration:

1. While planning an iteration, the user stories are break down into task level stories which will be easier for the development team to work on

2. Creating the acceptance tests for the tasks to check if the user stories are required to be built in the sprint and to check the priority of task

3. Creating the test strategy, test plans and test cases upon successful completion of the development

4. All phases are agile, hence the testing team continuously keeps testing the product in order to deliver the product to release by the end of the sprint

In Release planning we have tasks such as:

1. To check if user stories are developed the way to support the product and if there is a development from previous sprints

2. Determining the test plans and strategies and perform a high level of test planning to ensure there is no blocks for the release

After every iterations in the product, there are two main points that the product owner and the

scrum master have to focus on. They are: 1. What is the purpose of the iteration?

2. What are the activities performed in the iteration?The main purpose of the iteration is to work with the development team (Architecture,

Development, Testing teams) and produce a working product by the end of the sprint. The main activities performed in these iterations are code development and code review, testing and quality

assurance.These are some of the important phases for the release of a specific iteration.

8

2.4 Maintenance What is software maintenance and why is it needed?

Software maintenance in software engineering is the modification of a software product after delivery to correct faults and to improve performance or other attributes or adapt to a changed

environment.

The below described reasons are also the types of software maintenance.

Corrective maintenance – reactive modification to correct discovered problems. Adaptive maintenance – modification to keep it usable in a changed or changing environment.

Perfective maintenance – improves performance or maintainability. Preventive maintenance – modification to detect and correct latent faults.

Corrective Reasons:

Maintenance has to be performed to repair the existing faults in the software. This might include bug fixes due to bad code or a major system repair if the problem is advanced. Bugs may

also appear in case of change in hardware, OS or other accompanying parts in the system.

Adaptive Reasons:

A software ecosystem is continuously changing and regular maintenance is required to help it

adapt to new changes. Work patterns, software platforms, compilers, hardware upgrades etc. all affect the working of software.

Perfective Reasons:

One can also undergo the software maintenance process to fine tune the performance ability, functionality and usability of the software. It can simply range from changing the GUI of the

software to make it more attractive and user friendly to making drastic changes in the core code to improve the runtime and performance. One can keep building up on the initial work done to make

the software perfectly adaptive in the changing circumstances.

Preventive Reasons:

Preventive maintenance is essentially a preemptive strike against problems. By carefully

observing the conditions in the ecosystem, an expert can take decisions to re-engineer the software through data and code restructuring. This type of maintenance does not really contribute to the

functionality of the software, but rather acts like a vaccine to prevent problems and the additional repair costs that come with them.

9

Legal and Business Reasons:

It is not just the technological parameters that change with time, but also the legal and business

side of things. Adaptability is required not only to stay on par with the latest legal norms and requirements related to privacy and security of the users.

How will it help the product?

Maintenance fixes the bugs in the product after release improving the performance of the software and also new features can be added to the product according to the changing demands of

the customers and stakeholders.

Common types of software bugs:

Functionality Errors: It is a way the software is intended to behave. A software has a

functionality error if something that you expect it to do is hard, awkward, confusing or impossible.

Communication Errors: These errors occur in communication from software to end-user. Anything that the end user needs to know in order to use the software should be made available

on screen. Missing command Errors: This happens when an expected command is missing.

Syntactic Error: Syntactic errors are misspelled words or grammatically incorrect sentences and are very evident while testing software GUI.

Error handling Errors: Any errors that occur while the user is interacting with the software needs to be handled in a clear and meaningful manner, if it is not it is called as an Error handling error.

How often software maintenance is done?

Whenever a new product is released and after the delivery of the product on an as-needed basis. Realistically, software maintenance is done during the first year of operation after the delivery

of the product and thereafter on a periodic block release basis.

Who does software maintenance?

Developers are the ones who does it. Typically, teams made up of junior engineers work the

software maintenance tasks. Work can be outsourced because skills needed for maintenance are minor. Realistically, separate maintenance teams whose workforce is senior and more skilled and

experienced than the development team.

Agile model of software maintenance

Small projects with agile model and give bug reports/ story cards10

Give the developers estimation of cost and time

Customer prioritizes the bugs There should be a common bug tracking database

Quality Assurance team test and write functional acceptance tests Developers write failing unit tests and fix it, run unit, and functional tests

Perform Regression testing and finally new release

3. DEFINITION OF WORK-PRODUCTS, ROLES, & PRACTICES

3.1. Roles: Product Owner - responsible for outcome of the project and setting the priorities of the project.

Chooses the goals for the sprint and reviews the system at the end of the sprint.

Scrum Master - reinforces the project and iteration vision and goals. Mediates daily scrum meeting and conducts the sprint review.

Scrum Team - responsible for the outcome of the project. Tasks are to work on the sprint backlogs. The scrum team consists of developers and testers.

Chicken - stakeholders who are involved and consult on the project and informed of its progress

Table 3.1 - Iteration Roles by Team Members

Iteration 1 Iteration 2 Iteration 3

Product Owner Naga Ram Tou

Scrum Master Nithin Levi Ram

Scrum Team Kapardhi Nithin Nithin

Scrum Team Tou Tou Tom

Scrum Team Ram Kapardhi Levi

Scrum Team (scribe) Levi Naga Kapardhi

Chicken Tom Tom Naga

11

3.2. Work-Products:

Figure 3.2 – Work Products

3.3.Practices 3.3.1. Requirements Phase Planning Game

Onsite Customer <Removed because chicken is role of customer> Acceptance Testing

Pre-Game Planning (Scrum) Sprint Planning (Scrum)

Sprint Review (Scrum)

3.3.2. Design System Metaphors

Frequent Refactoring Simple Design

High-Level Design Phase (Scrum)

3.3.3. Implementation Frequent Refactoring

Coding Standards Pair Programming

Team Code Ownership <Removed because no owner needed>

3.3.4. Test and Verification Acceptance Testing Customer Tests

12

Test-First Development Unit Testing

Onsite Customer <Removed because chicken is role of customer> Sprint Review (Scrum)

3.3.5. Project Management Project Game Short Releases <Removed because Daily Builds are used>

Sustainable Pace Stand-up Meeting

Don’t Add To Iteration (Scrum) Chickens and Pigs (Scrum)

Pre-Game Planning (Scrum) Scrum Master Firewall (Take on external management & political issues) (Scrum)

Self-directed and Self-organizing Team (Scrum) Sprint Planning (Scrum)

Daily Scrum (Scrum) Sprint (Scrum)

Decisions in 1 Hour (Scrum) <Removed because telecommuting decisions instantly> Blocks Gone in 1 Day (Scrum)

Teams of 7 (Scrum)

3.3.6. Configuration & Change Management Environment Continuous Integration

Common Room (Preferred) (Scrum) Planning Game

Daily Build (Scrum)

4. PRE-GAME: PLANNING & STAGING This is the first stage in the project where the primary purpose is to discuss about the

requirements with the stakeholders. During this phase, our team participated in various meeting to discuss the following:

1. Vision.2. Requirements.

3. User stories.4. Project backlog and Estimates.

5. Architectural spike.6. Release planning.

13

We decided a product owner for our project; Ravi Malladi is the product owner for our first iteration. Product owner responsibility is to communicate with the stakeholder and working towards

creating the vision of the product and finalizing on the user stories for sprints. In our project, product owner was also involved in reading and understanding HW-1 outline for collecting all the

requirements of the customer, finalized and list down the user stories from the product backlogs. We later decided the vision and scope of the project.

4.1. VisionVision describes the application in brief. It helps in determining the goals of the project. It is the

medium of stating the organizational goals as well.

4.2. Short Description of the Application

The applications main goal is to perform the insertion sort algorithm. Insertion sort is a sorting algorithm that sorts the numbers one at a time. The application allows the user to register and login

to the application and provides a video for the user to understand the technique. The application also allows the user to provide feedback after using the insertion sort algorithm.

4.3. Goals of the ProjectThe primary aim of the project is to perform the insertion sort using the algorithm. We are

following the below aims to ensure smooth development of the application. Below listed are‘WHAT’ the project aims to achieve:

a. Build insertion sort application.b. Deliver the application covering all the specified requirements.

c. Deliver the application before the specified deadline - Sep 29 2015.d. Provide the user with simple and easy user interface.

e. Build a 99 % fault free application.

4.4. Goals of the Organization The primary aim of the project is to perform the insertion sort using the algorithm. We are

following the below aims to ensure smooth development of the application. Below listed are‘WHAT’ the Organization aims to achieve:

a. Provide a friendly environment to boost the productivity of the employees. b. Market Share

c. Customer Satisfaction.d. Quality of the product.

14

4.5. Systems featuresThe following are the features of the application:

1. The application shall perform the insertion sort.2. The application shall display the array of digits.

3. The application shall perform input validation.4. The application shall show animation while performing insertion sort.

5. The application shall show how insertion sort works.6. The application shall ask for user’s login.

7. The application shall ask for feedback.8. The application shall provide various themes.

5. VISIONIn the abstraction of our overall vision, we are producing the Insertion Sort product for all users

looking to benefit from the abilities to sort based on the popular Insertion Sort schema. This

Insertion Sort product will also be directed to any persons interested in enjoying themselves with watching how computing has evolved to solve some of the vexing numerical problems of our time.

The main feature delivered by our Insertion Sort product is the impression users receive from a secure and safe environment with which to play out their numerical hobbies as well as

mathematical interests, which will be on full display with our Insertion Sort application.

Our vision also looks to establish a comparative advantage from other industry Insertion Sort

applications by using state of the art SSL enhanced encrypted security to keep users information private because with today's level of intrusion by unscrupulous individuals. This will possibly try and

steal logins and passwords to check across multiple sites in hopes of vulnerabilities with respect to users’ insistence on not managing to0 many different username / password combinations.

With a product release date scheduled for September 27th 2016 and a focus on reducing cost through enhancing budget constraints we want to establish ourselves as the leader in an industry

typically dominated by massive corporations with unlimited budgets which actually gives our Agile Scrum development the greatest advantage of nimble development at the lowest cost.

In our vision summary, we strive to create a compelling environment for all establish an enjoyable safe connection to one of computing's earliest innovative breakthroughs.

15

As a role played as the manager I listened in on the scrum iteration 1 meeting and found all

participants playing their respective roles adequately. From the Product owner to the Scrum Master it was interesting to see the product backlog being developed in front of my eyes. I was very

satisfied with the outcome and learned an amazing amount about the whole scrum process and how efficiently all of the team members added valuable input throughout the differing questions asked

by product owner as well as Scrum Master.

We also came across multiple blockages but the biggest impediment was with the development

scrum team members wanting to use JavaScript instead of Android. We were able to come to a resolution by having the Product owner and Scrum Master agree on the path forward and finalize

the change with the professor.

Lastly, it was hard to play the role of Chicken because of all of the input I give during usual

meeting at my current work projects so having to play such a role of more stakeholder. This has allowed me to see across the table better and sympathize with some of the coworkers I sometimes

have concerns with because I have not in the past respected the valuable listening skills necessary to get a better feel for what ultimately make for a successful Scrum project using integrated Agile / XP

methodologies.

6. REQUIREMENTS 6.1. Functional Requirements:FR 1: The application shall perform the insertion sort.FR 2: The application shall display the array of digits.

FR 3: The application shall perform input validation.FR 4: The application shall show animation while performing insertion sort.

FR 5: The application shall show how insertion sort works.FR 6: The application shall ask for user’s login.

FR 7: The application shall ask for feedback.FR 8: The application shall provide various themes.

6.2. Non-Functional Requirements:Nonfunctional requirements helps the development team identify and understand the operation of

a software system. The nonfunctional requirements are important to document for future references. Some of the nonfunctional requirements for our process are listed below.

NFR 1: Interoperability: This informs that the system to communicate with itselfNFR 2: Reliability: This shows the users that the software is reliable to use

16

NFR 3: Portability: This shows that the application works on multiple operating systems

NFR 4: Maintainability: This defines that the probability of performing a successful repair optionNFR 5: Performance: The system should perform all the necessary that are given by the user.

Figure 6.2.1 – Requirements in Asana

Figure 6.2.2 – Requirements on Post-Its17

7. USER STORIES FOR PLANNING As a user, I want to login into my account so that I could perform insertion sort.

As a user, I want to give some input value so that the numbers are sorted. As a user, I want to see the output of the sorted numbers.

As a user, I want some examples of insertion sort algorithm so that I could understand it. As a developer, I want the page to load in under 2 seconds so that the application performance

does not degrade. As a user, I would want to use the insertion sort algorithm application on multiple device

simultaneously.

18

As a user, I would want to see and edit the source code so that I could understand the code by

introducing bugs and see the output. As a developer, I want to add the feedback option so that I could take the end user’s comments

and enhance the application in its further updates. As a user, I want to see my previous log results so that it saves my time if I want to check the

previously entered numbers again. As a user, I want to have a start over option so that there is no need of starting the application

to perform the insertion sort.

Figure 7 – User Stories in Asana

8. PRODUCT BACKLOGS & ESTIMATES During our simulation, the product backlogs were created by the Product Owner (PO) using the

user stories, requirements and nonfunctional requirements as references. The PO utilized a project

management tool called Asana to input the size point estimates. As referenced in the image above <insert image # here> the PO utilized the post-its and carefully thought through the difficulty of each

backlog that he created.

19

The size point’s estimates were based on a scale of 1-5 in which a 5 meant a really difficult and

complex task, and 1 being a fairly simple task. Based on the PO’s estimates along with some assistance from the chicken/stakeholder, he provided estimates similar to the one referenced below

for the product backlog.

Figure 8.1. – Detail of a Product Backlog in Asana

The other product backlogs were provided estimates and are shown in a CSV file exported from

Asana shown in fig. 8.2.

Figure 8.2 – CSV of Product Backlogs

*One thing to note from the referenced CSV file is that it also includes sub-tasks within each

backlog. As the screenshot was not captured right at the product backlog creation and estimation, sub-tasks were put in from the scrum team during iteration 1 planning, but the estimates should still

be displayed as a count from 1-5 for the product backlogs.

20

9. ARCHITECTURAL SPIKEThere were a few high risks items when considering the project. One of the areas was in regards

to the technology stack for the insertion sort. As the project asked to look at Android Programming,

the team looked at each member’s past experience. One of the concerns was that no team member had experience with Android Programming and the overhead would be too big for most team

members, thus limiting each team member’s contribution towards the development aspect of the project. Another concern was also the time necessary to be allocated towards training with less time

on programming, thus potentially not delivering the project on time. As such, the consensus was to use a programming language in which team members felt

comfortable with and it was to go with HTML5 and JavaScript. Another potential benefit of using HTML5 and JavaScript was the ability to utilize it on any platform. One of the limitations with

Android Programming was that it would lock the program to only be viewed on an Android device. However, by using HTML5 and JavaScript, we could create a program which would not have any

dependency on any particular device or platform. This meant that we could use it on any browser, whether it be PC, iOS, or Android, as long as a browser was available. Thus, rather than using

Android Programming we proceeded with HTML5 and JavaScript. Another risk to consider was each team member’s experience with coding. Not every team

member felt comfortable contributing by coding, thus we needed to account for it as part of our planning and estimation of resources. The solution was to allow the person to do what they felt mos

t comfortable doing, whether it was design or project management and thus allow them to maximize the team’s productivity. Although it was not a major concern, it is still necessary to

identify to demonstrate all potential risks toward the project completion. One other risk that arose was browser support. In order to limit the scope we limited it to IE9+,

Firefox and Chrome. As there are hundreds of browsers available, it would not be feasible to test every browser, so by limiting the types of browser we support it would make it easier for

development and testing.

10. RELEASE PLANNING Our release plan was to have the project completed by September 26, 2016. As this was a small

project without many features, there would be only one release plan, which would be broken up into three sprints. The expectation after the end of the release plan would be to have the entire project

completed and recorded with over video.

21

Figure 10.1 – Release Plan in Excel

Figure 10.2 – Release Plan Chart

22

11. TECHNOLOGY PREPARATIONThis had to be the most challenging up the technical application to this homework because we

had differing opinions on programming platform prior to the project beginning between scrum

team, product owner, and scrum master. Because some members already had time invested with the android platform and other scrum members had JavaScript background it was extremely difficult

to overcome this block huge during this cup scrum meeting. But after using a time box trap that the product owner made the final decision about changing to JavaScript because of its wider portability

architecture which was one of our non-functional requirements as well as the efficiency and speed for which we could develop in our current scrum role schema.

In speaking to our original technology preparation, we all took turns practicing the android programming environment using peer-programming methodology. We also went through Android

tutorials and demos for the android environments including some listed on Titanium class links. This gave us the expertise necessary two knowledgeably debate the pros and cons of android vs.

JavaScript and allowed the product owner the final decision with respect to these differing views.

In training for JavaScript for those without experience, the internet was a ready tool to search

and learn on it. As JavaScript is a popular front-end language for web-applications, there are much resources available for beginners. The following link [1] is a good reference and is available for free,

which was a good option for many who do not wish to pay to learn JavaScript. Following through the tutorial by my estimation it would probably take someone with no experience around 2-3 hours

until they have a general grasp around developing using JavaScript. The expectation of someone just learning JavaScript would be that they would be able to develop something small, and nothing too

detailed as it would require a bigger learning curve. For this project, having beginning programming experience would be more than sufficient, as the overall project in regards to code is not overly

complex.

In regards to best practices and recommendations for training, the suggestion is to try to get

through as much of the tutorial as possible following the examples. Although for some it will be more difficult at first in regards to understanding what variables are, functions and conditions, the

convenient thing about JavaScript is that you do not have to worry about declaring data types as JavaScript allows for just the use of “var” to represent any data type. This convenience helps reduce

the overhead when having to learn JavaScript from scratch.

Another convenient aspect of working in a scrum environment is the ability to work with one

another. For those without much experience, along with agile pushing for continual communication and collaboration, if a team member was stuck or had any questions with JavaScript then it was easy

to ask another team member who knew more about it. This allowed he team members to feel free

23

to ask one another in order to learn faster without the fear of making a mistake and getting ridiculed

as each team member understood the other’s position.

One other item that needed some preparation and training was on HTML5. Although we did not

use complex styles or markups, it was still important to have a general understanding of the DOM and elements within the DOM for easier manipulation using JavaScript. The training was very light

and was more focused on understanding DOM elements and how to retrieve the DOM elements using JavaScript. We had consideration for CSS also but as the time for the project was limited, we

felt having the basics of HTML5 was more important than including CSS.

12. DEVELOPMENT We define agile development as the key to creating higher quality software in reduced amounts

of time with respect to older methodologies. We also developed under the scrum approach for harnessing the benefits of the agile mentality. With also integrating XP into our agile development

we garnered even more rapid development times with increases in output as well as fewer blockage issues. Finally, for development definition purposes we want to focus on the improvements made to

allowing all employees to play some kind of role in the development process because getting confirmation by all team members will bring about the ultimate efficiencies as well as improvement

available to the Agile development methodology.

12.1. Sprint 1 12.1.1. USER STORIES

Product owner is responsible for gathering the user stories from the stakeholders by meeting and discussing with them. Ravi Malladi is the product owner. We collected the user stories during

the first meeting. According to the complexity, estimation hours and the priority list we have divided the user stories amongst various iterations.

The user stories intended to be focused in this iteration 1 are:

1. User login.2. Example/help guide for insertion sort.

3. Insertion sort algorithm.4. Security.

12.1.2. ITERATION PLANNINGFor the iteration planning, we subdivided each product backlog into task level user stories. In

the iteration planning, the product backlog were considered and estimation hours were assigned to

24

each user story in the current iteration. The estimation hours assigned to each user story helped us

in releasing the first phase of the iteration on time. We made releases during iteration 1.

Figure 12.1.2 – Sprint 1 backlogs

12.1.3. MANAGING12.1.3.1. Open Work Spaces

The team worked in an open environment to allow for easier collaboration and

interaction amongst team members. The open workspace was done at the California State University, Fullerton library, using an open table which each developer facing one another and

no walls. Figure 12.1.3.1 demonstrates the open workspace mentioned.

Figure 12.1.3.1 – Open Workspace Environment

25

12.1.3.2. Sustainable PaceDuring this iteration, we made a point of completing the tasks on time. We allotted precise

hours to complete the tasks assigned to each one of us. We worked at a steady pace and completed the tasks we committed to.

12.1.4. DESIGN In this iteration before development could proceed, the design was necessary to give an idea of

what the product would look like. Utilizing sketches that were drawn during the iteration as shown

below, we designed various options of the UI for the login and insertion sort algorithm. The various sketches allowed for team to review and determine what we felt would convey our product best to

users. As our iterations were condensed, we did not provide any high fidelity prototypes using any prototyping tools and kept it to sketches so that the developers could begin coding.

Figure 12.1.4.1 – Login UI Design

26

Figure 12.1.4.2 – Insertion Sort Page Design

12.1.5. DEVELOPMENT12.1.5.1. User Login Page Module > As well as description for Login while applying SSH encryption secure

We used a combination of JavaScript and HTML5 as well as CSS to style the Login page while utilizing the soon to be mentioned localDB held within supported browsers. With these

tools and testing followed the earlier laid out design to produce the Secure Login Home Page feature.

27

We also teamed up as scrum developers to slice each task into smaller decomposed

elements for easier sharing and development once we noticed our original estimations were slightly off with respect to development time.

12.1.5.2. Example Guide Page Element Module > Developed link and showcase element

We used an embedded link on the main page to allow users to access the example of Insertion Sort due to its layered complexity and unfamiliarity with most non-technical users. We

used the same earlier mentioned tools and platforms of a combination of JavaScript and HTML5 as well as CSS to styling to embed the link as well as visual embed for styling that we wanted all

to have access to, in order to better understand the Insertion Sort Feature.

12.1.5.3. HTML5 & JavaScript Web ApplicationThis is a single page web application. The User Interface is developed using the HTML5

and the CSS. The entire code is formatted using the HTML5 tags like <section>, <article>, <nav>, <header>. The Insertion sort is implemented in JavaScript. The input is accepted using the

HTML5 input text field. The restrictions on the input are imposed using the JavaScript conditional statements. The results are displayed to the user by manipulating the DOM

(Document Object Model). getElementById() (refer Mozilla Developer Network Documentation) is used to manipulate the DOM. The each iteration of the insertion sort is displayed to the user.

The application can be viewed here.

12.1.5.4. Login PageFigure 12.1.5.4 – Login UI

28

12.1.5.5. Insertion Sort AlgorithmFigure 12.1.5.5 – Insertion Sort UI

12.1.5.6. Example Help > - Example Help Page Element Module > Developed link and showcase element.

We used an embedded link on the main page to allow for users to access the example

help link due to its layered complexity and unfamiliarity with most non-technical users. We used the same earlier mentioned tools and platforms of a combination of JavaScript and HTML5 as

well as CSS to styling to embed the link as well as visual embed for styling that we wanted all to have access to in order to better understand and get any help deemed necessary by the user.

We also allowed for users to interact with the help by choosing the best help link related to the most relevant help necessary for any given page.

12.1.5.7. Develop Security Module > Encryption > Authenticate Component Code and description for Login while applying SSH encryption secure.

Our definition in this contexts is as follows A Security Architecture is a cohesive security design, which addresses the requirements such as: authentication, authorization, etc., and in

particular the risks of a particular environment/scenario, as well as specifies what security controls are to be applied where the design process should be reproducible.

One of the main aspect layers to our Security Architecture has to do with Encryption and how we implement a secure connection throughout the login and interactive connected user

activities process.

29

The main aspect of the Security Encryption will be to implement a secure token key 128

bit encrypted using HTML SSH protocol for establishing the said secure connection. We will dynamically generate token for accepted on platform of choice and leave secure for 30 days

before expiry process is required for renewal of a new token.

With the completed process of integrating our Encrypted Security functionality, we also

look to validate through login any possible unauthorized access from a said database of requested and approved users.

Relationships and dependencies as an important part of the overall Architectural design can be discussed in the following excerpt "The scenario/requirements addressed by, a security

architecture includes the relevant IT architecture. In this section, we use the term “Reference Architecture” to identify the idealized model from which the “Solution Architectures” are

derived.

Our reference architecture for Information Security will help to also address the issue by

providing a modular set of reusable security services that can be deployed strategically and reused across all of our projects necessary pages. As we modularize our loosely-coupled security

architecture, components can be upgraded or replaced as required to meet changing threats without having to re-architect the entire strategic security infrastructure.

To conclude the final implementation of Security through Encryption, we look to test across all connected Architectural platforms and also allow for future maintenance of ever

changing Security Encryption updates with respect of vulnerabilities that arise from unscrupulous groups as well as individuals looking to penetrate our regularly updated derived

security system.

Code SSH Initialization Section = ssh-keygen

Generating public/private RSA key pair.Enter file in which to save the key (/home/.ssh/id_rsa):Host *

StrictHostKeyChecking no UserHostsFile /dev/null

Host localhost

HostName InsertionSortLogin.com StrictHostKeyChecking ask

UserHostsFile /home/demo/.ssh/known_hosts

ssh-keygen -t rsa -C "[email protected]"

30

12.1.5.8. Platform The Insertion Sort algorithm is developed as a Web Application, by using HTML5,

JavaScript, and CSS Technologies. This is a Single Page Application. For the purpose of the login and Signup, local browser storage is used to store the user credentials. IndexedDB is an inbuilt

browser database, Stores the data in JSON format). The user authentication takes place at the client side. This application is responsive, the user can view the same layout of the application

both on the Desktop and mobile. Twitter Bootstrap API is used to design and implement the responsive design.

This application supports only Chrome and Mozilla Firefox. The user experience may be varied if Internet explorer is used. The application runs over the HTTPS Protocol. To implement

the download source code feature, the application is hosted by using the Google app engine or other web hosting services. Then the code is made available as the pdf file for download. The

encryption functionality is implemented using the Socket.io functionality provided by the HTTP protocol.

Figure 12.5.8 – Team Development

31

12.1.5.9. Daily Builds We executed on daily builds after each daily development tasked cycle was completed.

This included compiling, looking for bugs and finally testing for any anomalies with respect to featured outputs. In this first sprint iteration, we had the core sprint 1-backlog products coded

and ready for the daily build. We fell in love with daily builds because it allowed us to realize the development progress in real time.

We also received the satisfaction of knowing all of our hard work was steadily progressing to our ultimate goal of a successful Product Release. Lastly, we rotated daily builds

between different development scrum team members to add to the eyeballs as well as add differing programming views on how to most efficiently refactoring any underperforming coded

components.

32

12.1.6 TESTING 12.1.6.1. Acceptance Testing

At the completion of the backlog, the tester would test what the developer marked as

completed. The tester worked closely with the developer to make sure that the sprint backlog could be closed. The tester had to make sure that the developer met the criteria set and

satisfied the user story. This was true for the case of the login, example of insertion sort, and security for the first sprint.

12.1.7. DAILY SCRUM MEETINGThe team participated in the daily scrum activity every morning in the library. The scrum

master along with the product owner and the developers met for a fifteen-minute meeting to

discuss the progress of the work in the sprint. The scrum master made sure that the developers had no blockage to progress with the work and the product owner in the team ensured that the

vision is maintained and the team is not deviated in terms of the user stories for the sprint.

12.1.8. BURNUP CHART SPRINT 1

Figure 12.1.8 – Burn-up Chart Sprint 1

33

Figure 12.1.8 above represents the burn-up chart for Sprint 1. Although, it displays all 3 tasks

completed one, if you reference back to the iteration planning there had been 4 product backlogs that needed to be delivered. However, due to time constraints (insertion sort algorithm) had to be

pushed back to sprint 2. The main feature of the product backlog was completed; however, due to an additional feature that was requested by the client (quit button and animation) the product

backlog was not able to be fully completed.

As the scope of the backlog grew, the Scrum Master asked the PO if the backlog could be

pushed into Sprint 2 in order to implement the new features requested. The PO understanding that this feature was not part of the original product backlog signed off on having it pushed back to sprint

2, thus the burn-up chart only demonstrates 3 completed product backlogs for sprint 1.

12.1.9. SPRINT 1 REVIEWDuring the sprint review, the scrum team conducted a meeting to the PO and client of the

completed features, such as the login page, the security and the example video of the insertion sort algorithm. Although the expectation was for the insertion sort algorithm feature to be implemented,

due to the additional feature being requested, the team demonstrated that the effort of the team was still productive in sprint 1 by demonstrating that the other three features were implemented

and passed all acceptance tests so the product was still on schedule to be completed.

12.2. Sprint 212.2.1. USER STORIESIn this iteration, we plan to cover the following user stories:1. Insertion sort algorithm.

2. Download direct source code.3. Start over insertion sort.

12.2.2. ITERATION PLANNINGIterative development added quickness to our development process. For the iteration planning,

we divided the product backlog into implementable tasks. In the iteration planning, the product

backlog were considered and estimation hours were assigned to each user story in the current iteration. The estimation hours assigned to each user story helped us in releasing the first phase of

the iteration on time. We made small releases during iteration 2.


We had to meet several times during our project. We used to have meetings in the California State University, Library. The scrum team was put in a group and at the same table so that they

could work together.34

12.2.3.2. Sustainable PaceDuring this iteration, we made a point of completing the tasks on time. We allotted precise


12.2.4. DESIGNFor this iteration, the primary feature that needed UI design was start over feature. As the

insertion sort algorithm backlog was carried over from the previous sprint, the design for it is

mentioned in sprint 1 design. The design was just a simple paper sketch and not a high fidelity prototype due to time constraints.

Figure 12.2.4 – Start over UI Design

12.2.5. DEVELOPMENT12.2.5.1. Download Source Code feature

We used an embedded link on the main page to allow for users to access the Source

Code for Insertion Sort as an open source type project and allow for other developers to enhance the features is deemed worthwhile.

We used the same earlier mentioned tools and platforms of a combination of JavaScript and HTML5 as well as CSS to styling to embed the link to the Source Code as well as visual

embed for styling that we wanted all to have access to in order to better enhance the Insertion Sort programming.

12.2.5.2. Performance NFR

35

We developed on the JavaScript platform not just for the enhanced portability support

over a forked locked down Android Java implementation but because of the performance enhancements with JavaScript as most modern browsers have JavaScript built into the kernel

allowing for faster runtimes with higher performance.

12.2.5.3. Start Over Insertion Sort Reload JavaScript Module >

Component Code and description for Reloading Insertion Sort Page for running

additional Insertion Sorts after the completion of each individual Insertion Sort. We look to designate the Reload Start over Button functions.

We next program the call to which JavaScript will use to reload the original existing Insertion Sort code, thus allowing users to start the new Insertion Sort after completing a

successful or failed Insertion Sort Attempt.

<FORM>

<INPUT TYPE="button" onClick="history.go(0)" VALUE="Refresh"></FORM>

<A HREF="javascript:history.go(0)">Click to refresh the page</A>

12.2.5.4. Pair programming We wanted to fully practice in an Agile / XP Software development technique so we

chose pair programming where Ram and myself Levi sat together at one computer station to write the code for our secure encrypted connection. As we switched roles it was amazing how

fluid are thinking was and how we were able to overcome obstacles by improving on each other’s basic coding approaches. Realistically it was also enjoyable being able to work so closely

with smart people in attacking problems instead of getting tired and frustrated when certain coding glitches arise.

It was through this Pair-programming that I was able to learn and think about testing and maintenance ahead of time and incorporate it into my coding expertise methodology, which

in the past I had neglected. Working with other programmers that have a gift from mindset to programming really does stretch one's skill set any calls into something very new. I would

recommend pair programming for anyone looking to expand their overall knowledge the most importantly becoming more efficient programmer.

12.2.5.5. Daily Builds

We continued executing on daily builds after each daily development tasked cycle was completed. This included compiling, looking for bugs and finally testing for any anomalies with

36

respect to featured outputs. In this second sprint iteration, we had the second sprint 2 backlog

products coded and ready for the daily build.

We continued our passion for daily builds as it allowed for us to continue the realization

of our development progress in real time as well as gave us the satisfaction of knowing all of our development work was nearing completion to our ultimate goal of a successful Product Release.

Lastly, we continued rotating daily builds between different development scrum team members to add to the eyeballs as well as add differing programming views on how to most efficiently

refactoring any underperforming coded components.

12.2.6. TESTINGCase testing on multi-platform, performance architecture

12.2.6.1. Acceptance Testing● Final string order● Performance verification by different platform

● Responsive display by difference devices.

12.2.7. BURNUP CHART SPRINT 212.2.7.1. Beginning of sprint 2 burn-up chartFigure 12.2.7.1 – Burn-up Chart at Start of Sprint 2

37

12.2.7.2. End of Sprint 2 Burn-up ChartFigure 12.2.7.2 – End of Sprint 2 Burn-up Chart

12.2.8. SPRINT 2 REVIEWSprint 2 concluded with the project on time. Unlike in sprint 1, there was no sprint backlogs that

remained open and so the project looked like it would continue what we had planned in the release

planning. The scrum team demoed the application to the product owner and customer. As this sprint contained the main feature of the product, the client was happy that they could get a glimpse

of the expected product.

12.3. Sprint 312.3.1. USER STORIES

This is the last iteration, so we have decided to complete the following user stories:1. Log of previous results.

2. Feedback feature.3. Responsive design.

12.3.2. ITERATION PLANNINGFor the iteration planning, we divided the sprint backlogs into implementable tasks. In the

iteration planning, the sprint backlogs were considered and estimation hours were assigned to each

user story in the current iteration. The estimation hours assigned to each user story was the expected amount of work by the scrum team with each team member providing their estimated

amount of work for the task. At this point some team members would also volunteer to take ownership of the backlog.

38


The team utilized an open workspace at the California State University, Fullerton library with an open desk area and white boards to allow for mocking designs and discussion. The open space allowed for easier collaboration and interaction amongst team members.

12.3.3.2. Sustainable paceDuring this iteration, we made a point of completing the tasks on time. We allotted precise


12.3.4. DESIGNThe primary areas of design of the UI for sprint 3 was the log of previous results and the

feedback system feature. As these had not been previously worked on, we provided paper sketches

to give development a better idea of the direction we wanted to go towards. The team decided upon which design we felt would best convey the feature prior to development.

Figure 12.3.4.1 – UI Design for Log Results

39

Figure 12.3.4.2 – UI Design for Feedback System

12.3.5. DEVELOPMENT12.3.5.1. Responsive Design

We wanted as the user story suggest allow for any user from any device have access to the

Insertion Sort functionality product which is why we chose the JavaScript platform allowing for almost every mobile or desktop device to be compatible with our Insertion Sort product rollout.

After much testing and feature review we believe users will be extremely satisfied with the responsive design as well as the ultimate performance.

12.3.5.2. Feedback Submission Form JavaScript Module

Description for Feedback Submission Form we used JavaScript to define our backend table field

assignments and relations then executed a standard default Submission Feedback Form template for use in this process. Finally, we customized the Feedback Forms UI to correspond to our earlier

design layout.

12.3.5.3. Log of Previous Results We developed the Previous Results button and history results for users interested in past

Insertion Sort numbered entries. We used the same earlier mentioned tools and platforms of a 40

combination of JavaScript and HTML5 as well as CSS to properly stylize the Previous Results button

and Insertion Sort history results display schema.

12.3.5.4. Daily Builds In our final iteration we continued executing on daily builds after each daily development tasked

cycle was completed. This included compiling, looking for bugs and finally testing for any anomalies with respect to featured outputs. In this third and last sprint iteration we had the third sprint 3

backlog products coded and ready for the daily build. We finalized our daily builds with the knowledge that following the integrated Agile / XP methodologies has allowed for us to continue the

realization of our development progress in real time as well as gave us the final product to accomplish our product vision. Lastly, with the continuous integration up into our last daily build we

accomplished a level of source code control that made for a rock solid, thoroughly tested product release.

12.3.6. TESTINGVerify performance and responsive display by multi-platform using test case. We suspect the

performance by different platform might have outstanding different, after using test case from

different platform, we did not notice it. Worst case of reverse numeric string to test algorithm is used.

Develop responsive display, following test case from multi-platform, this feature is to make sure any device or screen size can display app properly. Adding display driver per platform and devices.

12.3.6.1. Acceptance testing: The team developed the backlogs that were to be completed in this sprint and has met the user

stories requirement. The first user story was to develop the log of previous results. The criteria has

been met by the team. The log of previous results can be viewed in the application and hence satisfies the acceptance test. Another acceptance testing was done for the feedback system. The

user has an option to provide feedback to the application and this feature is implemented and works properly in the application. The application is a responsive design. The application has been checked

on a smart phone, laptop and tablet and application size dynamically changes with the screen size.

41

12.3.7. BURNUP CHART SPRINT 3

13. RELEASE With our high-level view of the three sprints discussed throughout our project, we see the tight

correlation with implementing the product backlog with a focus on vision, goals, schedule, scope, and all other resource related project necessities.

As we created the Release criteria during the early scrum meetings, we constantly updated in an agile fashion as the differing environmental factors affected the Release as an ultimate work product

roadmap. Our To Do list was used with great effect to offer a point’s scale for keeping release goals in proper estimation boundaries with respect to user stories.

In completing each requested function, we checked back to the Release goals and plan for guidance on the next iteration tasks for continued to process each user story at varying revisiting of

past iterative blockages.

Synopsis:

The supreme insertion sorters application accepts numbers from 2-9. The application takes the user’s inputs and applies the insertion sort algorithm to the entered numbers and the numbers are

sorted. The sorted numbers are displayed on the screen and the user can start over the process by clicking on the start over option. The user can view his previous logged values and its result.

The following are the features of the application:1. The application shall perform the insertion sort.2. The application shall display the array of digits.3. The application shall perform input validation.

42

4. The application shall show animation while performing insertion sort.5. The application shall show how insertion sort works.6. The application shall ask for user’s login.7. The application shall ask for feedback.8. The application shall provide various themes.

14. OTHER ACTIVITIES 14.1. Estimation

We used estimation story points as the key to having a successful estimation process. The main

benefits to our estimate in process was the fact that some of our team members currently are employed in working business establishments that use the scrum process at their places of

employment. We found that if we focused on the user stories and application of the applied past endeavors even though estimations were slightly off target we found it quite satisfying from a

statistical standpoint of how much time it was taking to implement all of the products / features derived from our earlier iteration zero. In our learning process, we used story points at the product

backlog level. This allowed for better estimates with the 1 to 5 level of difficulty in processing the task / feature from a product owner’s perspective who does not have much technical experience.

In addition, we also provided estimations during the sprint planning for the start of each sprint. Going around the table, the scrum team provided their hourly estimates of the sprint backlog. As

each team member provided their estimate along with their rationale, the scrum master, picked an average between the team members, and then asked if this average was reasonable. If the team

decided that it was, then the scrum master would input the estimate. A team member would then volunteer to take on the sprint backlog to be completed for the sprint. The estimations provided the

scrum team with an idea of how much effort would need to be allocated towards completing it. Though not exact, the overall consensus was that it encouraged more participation from team

members as there was now some idea as to the amount of work requested. If left with uncertainty and no estimates given, it would discourage scrum members from volunteering, as they would not

have an idea of the requested effort. Not everyone is willing to work on a sprint backlog with no foreseeable closure, so providing estimates aided them in choosing which sprint backlogs to pick.

In conclusion, the real benefit to estimation lies within the growing statistical monitoring as to how much compiling monitoring time data on all aspects of the agile process of applying those past

product successes to help pave the way for a truly accurate estimation for the implementation of future projects which lends itself to easier estimating and task execution. By practicing estimation, it

provided those without prior experience understanding to the difficult task of estimating. At the end of the project, one thing that stood out was the team under-estimating the amount of work

43

required. By providing low estimates, the team wound up having to work additional hours in order

to complete the tasks on time for the sprint. As such, it was a good experience for those without experience in providing estimations so that moving forward they have a better grasp on estimating.

14.2. Project PlanningFollowing agile process as project plan to be managed by feature based, time bound iterations

and expressing different levels of detail depending on the period. We kick off pre-gaming stage to prepare for team role and availability to meet. We began with all team members to write down

features and user stories for target goals. Plans are developed in the manner based on the assumption that all team members understand their role per stage and will commit to the tasks they

promised. We presume the Project Manager can predict up front everything that will need to happen in the project, how long it will take, and who will be able to do it.

The plan projects when features will be delivered to production, without much detail surrounding how those features will be delivered, by each iteration a bit more information was

added to the project plan. We did not know exactly what will go next but following the spirit that each member commit and complete their tasks. Our plans are based on the assumption that we

don't really know what conditions, but we can put together a reasonably good guess about what will be delivered when, based on the priority of the features and how much functionality the team can

deliver within a given timeframe.

At each meet up, either scrum meetings, sprint meetings… the whole team owns the plans; we

work with the product manager and chicken to decide what functionality will be produced in an iteration, and decide what tasks are necessary to successfully deliver the planned functionality in the

upcoming iteration. Right after the plan is developed, we use the software system to maintain and monitor it: each member self-select the tasks that they will complete and update the status

accordingly, people who are doing the work, they are best positioned to know what needs to be done.

14.3. Project Monitoring & Control What we did for project monitoring was utilize a web-based tool called Asana. Asana is a

simplified project management tool that allows the team to see the status of the project along with the sprint backlogs due for each iteration. Although there were more intuitive and in-depth project

management tools such as VersionOne in which multiple team members have experience with, we decided on Asana because it was free and was simple enough for first time users to grasp. Unlike

VersionOne, where it can be very complicated, the tool was meant to be a supplemental tool to the project and not additional overhead for them to use.

44

When the project started the product owner and team went through the requirements, non-

functional requirements and constraints. Utilizing these, the product owner made stories into Asana so that each team member could see the user stories. Then with the user stories developed, the

product owner created the product backlogs and together with the customer decided upon the priority of each backlog. As this was all done with Asana, it was easy to link the user stories with the

corresponding backlogs making it easy to see the relationship. Once this was completed, then during the sprint planning when the scrum team volunteered to take on the tasks, the product owner could

see the progress of the project.

When the first iteration was getting closer to completion and some of the backlogs were not

being updated or completed, the product owner raised the question to the scrum master. Although, the tool is not meant to be used to micro-manage the project, it was a good indicator as to seeing

where the project was going. In the instance of the first iteration, the Product Owner by raising the issue along with the additional change request (see configuration management section) came to find

out that one of the sprint backlogs was not going to be completed for the first sprint.

This was a cause for concern; however, at looking back at Asana and the expected items to be

released for the next two sprints, it was possible to push this particular sprint backlog to the next sprint without major delays to the release of the project. Another useful feature of Asana was the

ability to view a burn-up chart (in this instance rather than going down to see the tasks completed it went up) to view the progress of the project. This was helpful for including at the end of each

iteration when the burn-up chart was necessary to review whether or not all the sprint backlogs were completed.

Overall, the simplicity of Asana allowed every member on the team to check on the status of the project. This help provide accountability to each team member as they could also see whether

something was falling behind. In one case, where it looked like there was no progress on a sprint backlog, another team member went and wrapped it up as they had the knowledge and experience

to complete it on time for the sprint. This allowed for easier collaboration and each team member not having to constantly ask what needed to be done, what was completed etc. At the same time,

from a high-level perspective, it provided insight on the progress and status of the project without having to breathe down the necks of the developers. To view some examples of the burn-up charts

reference (sprint 1, 2, or 3 burn-up charts) of how the progress was checked for each sprint.

14.4. Quality AssuranceThe sole purpose of the project team is to provide a high quality software to the customer. We

performed various quality activities throughout the project in order to maintain the value of the

product being built. In our project, one of us performed the role of a tester to check whether we are developing a system with utmost quality. The tester helped to put the developers and product

45

owner on the same page. He helped the team in identifying the risks, modified them and assisted in

delivering a good quality product at the end of every sprint. His feedback to the development team was very crucial in maintaining the quality of the product and he also generated test cases covering

all the requirements.

In order to check the scalability of the application the tester looked on to some performance

testing factors such as the response time, load, mean time and time to failure. We believe, documentation is very important for the project’s success, so in order to keep us up-to-date we used

to document at every stage. We made sure that we follow the agile methodology for completing our project. For the project management we followed Scrum and for developing our project we followed

XP.

With quality assurance our focus we used these main principles for applying quality assurance to

everything we do. This starts with using practices, tool, and testing methodologies that follow the predefined processes created from the Agile Manifesto. Next, we want to add value in these quality

assurance principles by always watching for areas we can remove issues that slow down and do not strengthen the sprint process. As we wanted to apply quality assurance throughout our processes it

also helped us to invoke a test always mentality whereby when we created code we keep in the front of our minds the benefits of being able to easily test.

Lastly, we wanted to make sure that all of the members of the scrum team had quality assurance buy in and understood exactly what was expected to keep our quality assurance

principles applicable throughout the complete Agile process with as much communication between members as deemed necessary.

14.5. Configuration ManagementConfiguration management was a process that we were able to handle within our project.

Although there are many instances of configuration management, the one we encountered was with the changes to include a feature that was missed, in this case the quit button and animation. The

feature was missed as it was overlooked within the homework outline; however, when it was caught it was already during the implementation of the first iteration (sprint 1). As such we simulated what

would have happened if this were a real life situation. As our iterations were short, 2 day iterations, what ended up happening was the product owner discussed with the client on the feature.

The change control board (CCB) which we put together consisted of the PO, stakeholder (chicken) and scrum master, discussed whether this would be able to be included into the sprint as

the product backlog was being worked on for sprint 1. The CCB agreed that the feature was necessary but the product owner wanted the scrum master to discuss with the development team if

this would be feasible to include. The scrum master in having discussed the new feature with the

46

scrum team was told that it would not be feasible as there was a task within the sprint 1 backlog,

insertion sort algorithm that could not be completed for iteration 1. As such, the scrum master asked the product owner if they could carry over the sprint backlog to the next sprint but have it as

the top priority. The product owner was not happy with the reply as the insertion sort was the main piece to the product; however, the product owner understood that rather than demonstrating the

feature without all its parts could lead to bad results .The product owner then negotiated with the client on pushing this feature out to the next sprint with the trade-off that the login feature would

be fully completed along with the security. The client agreed and therefore the product owner signed off on having the sprint backlog pushed into sprint 2.

Therefore, in our situation the process we had in place was that the CCB was responsible for accepting whether a change request could be accommodated. If it was approved, then the scrum

master needed to notify the team if it was feasible based on the status of the project. The scrum master was responsible for acquiring the current status of the team during the daily meeting and

notifying the product owner. In our case, as the scrum team was behind, the scrum team had to receive approval from the product owner in order to push the sprint backlog to the next sprint.

However, in our process, the product owner had final approval of whether or not the sprint backlog could be pushed out.

In determining our configuration management, we left the approval up to the product owner as they were the one interacting with the customer/client. In our case, if the product owner had said

that they had to complete it, then the sprint backlog could not have been pushed back and the scrum team would have been responsible for delivering it. However, as the product owner

understood rather than pressuring his team to deliver a half-baked feature along with added stress, and there was some leeway in sprint 2, due to there not being as impactful of features required to

be delivered, the product owner decided it was okay.

14.6. Risk ManagementRisk Management is a delicate balancing act for any Scrum Master and / or Project leader

because one has to not be too negative about risk management while at the same time not overlook

obvious risky concerns with regards to the project at hand.

The top three risk issues I have come across that we addressed in our Homework 1 had to do

with Scheduling Flaws, Requirements Changes, and poor Estimation because of lack of experience in the estimation discipline. We were working as a team to address these risk issues by using the

professors rebalancing the workload from product backlog features broken down into tasks. This is in the pursuit of making sure that when adding the new requirement for a quit button we used the

sprint planning attributes to address the risk concerns as we added this feature addition as well as all the other re-estimations that occurred in the multiple sprint iterations.

47

We also followed the overall goal of risk management process which is trying to most effectively

decrease any issues that arise from unrealized risk. The additional process we followed started with Agile risk identification, Agile risk assessment, Agile risk response, and finally Agile risk review which

gave us great insight into what issues to watch for throughout the complete Agile process. One of the best places to respond to possible risk threats in the current sprint planning whereby each

member can work as a team to identify, visualize, and risk that may be present in the upcoming sprint iteration.

We finally want to use the sprint retrospective to discuss the possible improvements that can be made going forward with respect to risks that we can focus on as we take on additional agile

projects going forward.

14.7. Testing

There were many instances of testing conducted throughout development. The first instance of testing was at the unit testing level. At this stage most of the testing was done primarily by the

developer to test his code. As this was a web application an easy way to test it was using the browser debugger. The browser we used was Chrome, so by pressing F12, you could debug the

code. Using the Chrome Debugger you can determine if there is any error with the code. Another nice thing about the Chrome Debugger is that it allows you to see the DOM so you are able to view if

an element is misaligned or not present which definitely helps with our project as it is a web application. For Firefox, we used Firebug for debugging, which is an extension that can be

downloaded and have similar capabilities to Chrome’s debugger. One thing that occurred when unit testing or white box testing, was that depending on the browser type some errors appeared

whereas in the other browser it did not. As one of the points we wanted to emphasis on the product was on being browser and device independent, it was important to test on both browsers along with

IE, which has a built in debugger similar to Chrome. Therefore, it was necessary that we tested against these three browser types to make sure that it worked on all three. An example of an error

that was caught during unit testing was an unexpected identifier, in which the developer was still learning and did not realize that he had put one too many “)” causing the program to crash, but him

being unaware of what was causing the issue. Using the debugger, we could walk step by step to where the problem occurred. Additionally, the debugger also allows to jump to the line of code it

thinks is causing the issue, so it also helps in catching and fixing mistakes. Luckily because he performed this unit testing was he able to catch the error before having checked it in or just giving

up assuming that he was a bad developer. This was one form of testing that was done for the project but not the only type that was conducted as will be described in detail in the following

section.

48

Another form of testing that was conducted was acceptance testing. The acceptance testing was

made by the Product Owner and Client in what would satisfy them in regards to having the user story completed. This form of testing is at a higher level than unit testing as it a form of black box

testing without having to understand what the code is doing. This is more effective when one is not necessarily as technical and is more concerned with the features. Therefore, this form of testing has

greater appeal to clients in regards to if the product is satisfactory or not. In our simulation, most of the sprint backlogs were put up against acceptance tests prior to the sprint review. This was done so

that it was verified that the backlog was completed and was presentable to the product owner and client. The one we had primarily doing this testing was the tester on the team. The tester role

shifted each iteration but each person took turns into validating that the backlog met the acceptance test in order for it to be marked as completed.

15. LESSONS LEARNED15.1. Levi Martin

The process of using Agile Method and XP Programming my experience with the integrated

process has redefined how I know apply my Agile practice thinking as well as Extreme Programming practices that help me be more efficient and nimble with respect to all projects I am currently

working on in university classes while also all of my work software project.

We started by building our own agile process then defined these processes, which taught me

the amazing clarity of purpose on what needs to be done at every level of future activity processes. I also learned that most of the thought process to apply the agile process in a way that helps move

through the whole project with strict guidelines but also allowing the useful changes required when certain unforeseen issues arise.

With lessons, I learned from enforcement of process through this homework I was able to realize the blockage and team members who were not following the original laid out Agile defined

process. As a group, we removed the task either if not finished and reassigned or decomposed for easier execution. This was a great enforcement mechanism that did not single out individuals for

failing on estimates but actually allowed for all team members to look forward to communicating the need for help in order to complete any self-committed task.

The best thing I learned from this Homework 1 is the complete implementation of properly executing a Software Project with an integrated method using Agile as well as XP. I had not done this

much preparation for software projects in the past and I learned after homework 1 execution that my past projects lacked the proper process definitions and planning before executing my past

projects leading to dire failures and upset managers as well as customers. One final note I learned 49

that was the ultimate value I learned going forward is to have as much communications with team

members that Agile Method affords while at the same time Micro Application Methodologies Development execution which dissection of Extreme programming allows.

I would be helped most from being able to process software related tasks more efficiently so additional practice in the complete Homework 1 will allow for my experience level to increase to

where I am somewhat of an expert with respect to the Complete Management of the Whole Software Process.

In conclusion, we have all had our worlds exposed to a completely new way of thinking with respect to Agile / XP Software Management that we did not previously known even existed. Even

with our extensive practices of Homework 1 we all feel as though we have a feeling and a firm grasp of all of the differing requirement for each stage of the Software Process Maturity Levels.

15.2. Ram Anudeep KuchibhotlaThe lesson I learned from this homework is to establish and follow a standard process in building

a good software product. A process which is carefully formulated saves resources and dividing the work into subtasks, prioritizing and implementing the tasks assists in a better process monitoring

and control. With this homework, I actually learned how an agile process and with the scrum meetings and the sprint review I could relate them with the real time meetings. Working on this

project, gave me an insight of how to overcome hurdles when any problems occur during a project. Overcoming the problems require experience.

Coming from different educational backgrounds, these group meetings helped me excel my technical expertise personally and understand the agile process i.e. Scrum and Extreme

Programming. Working together as a team helped each member get to the base point of the project and frequent meetings helped each member clarify the doubts and we collectively as a team could

complete the homework.

Completing this kind of homework’s would help me in understanding the actual process that is

followed in companies and Frequent interactions with professors and my fellow students who outclass in this would be an added help in strengthening my skills. Getting involved in all of these

activities, I would practically able to apply the gained experience in my future endeavors.

15.3. Tom WangThis is my first class practically went through process model and try to simulate real situation.

Other than development module from previous class, the topic of process is to set a guideline of

software development, which is also new to me. My age when developing software system, we normally discuss about PMP, project schedule, cost and customer's’ acceptance criteria. We

presume other than that are all development team’s internal tasks to follow but normally it is not 50

the case. We are expecting project manager and product owner to as stakeholders of everything

else.

My outstanding lessons learnt from homework#1 is to see tools and team working together

following Agile process spirit, which in the real world we work with mobility as sprint team. I am very unfamiliar of the process software of what the system can help tracking, and generating

documents. We follow agile spirit not to define the goal but for the team members to pick their own tasks, status was updated by E-mail notice and SMS to mobile phone. Now we have went through

first stage of experiencing process model, I am very exciting to go through process review.

15.4. Naga MalladiThe combination of agile methodologies with scrum and Extreme programming is one important

thing I learned from the homework. The homework made us understand the process of software

product development and how is it used in the industry. The homework made us work on the products requirements to testing and how does it affect the product if one step is missed. This gave

me overall understanding of requirements, design, working on function and nonfunctional requirements, user stories, sitemaps, design flows, architectural spike, prototypes, algorithm,

development and testing. Following the agile process with scrum and extreme programming helped in understanding the fast pace work culture and working with cross-functional teams and handling

various titles like product owner, scrum master, developer, and chicken.

I understood the importance of daily scrum meetings, product backlogs and how much effort is

involved in maintaining and defining the scope of the project. Understanding the process on a whole was a wonderful experience and these methodologies helped me understand various advantages of

following process. The team meetings helped to understand and divide the work better among team and working in an open space environment helped a lot in solving problems easily and for better

work result. The most challenging part was following the process, other than that one other thing was combining Extreme programming and agile methodologies.

Though it was initially difficult to inculcate both the methodologies into the project, later we understood that certain elements were developed easily when combined. Before the project, I was

inclined towards agile methodology solely, but now that I understood the advantages of pair programming and Extreme Programming working benefits, I enjoyed the process of combining. This

new methods will definitely help in the future when we get to work in the industry.

15.5. Tou MouaOne of the lessons I learned from this project were the various practices of Extreme

Programming. Previously, I have had prior experience with scrum; however, Extreme Programing was new and something I had not practiced before. Although the process remained, the same, extreme

51

programming focused more directly on programming and not so much on a multiple team collaboration environment. This made it interesting incorporating the two processes together as when simulating the iterations, I knew what to do for scrum but had to remember to consider what work-products and practices must be done for extreme programming. It was also a good balancing of the two, as one of the reasons agile is effective is due to its flexibility. However, by incorporating both scrum and extreme programming together, it was one process on top of another making it feel a lot more rigid in how to incorporate it.

However, navigating through the simulation was quite interesting and definitely helped me learned a lot more on the aspects of extreme programming that are not part of scrum such as the differences in roles of the coach compared to the scrum master. These small variations were enough that when we decided upon our process and what roles I had to consider did we need both as their tasks and goals did differ slightly from the scrum master. Ultimately, we decided to move ahead with the scrum master as many of the tasks could fall under some of the expectations of what a scrum master would do to aid the scrum team due to his depth of knowledge.

15.6. Group LessonsOverall, the group experience was good. Team members took part in simulating the roles and

each person has to experience the perspective of different roles. This allowed them to try different hats and to be able to contribute on the report while not only from the perspective of one role but from all the roles. It was also good seeing team members experience agile for the first time and navigating their way around. Agile allows for a lot of flexibility; however, in this case as we had to follow scrum and xp processes, if they diverged too far towards traditional, which is natural as we have grown to learn things that way, then we could steer them back. The most interesting part for me was the estimation during the sprint planning.

Having had prior experience in development and providing estimates, it definitely helped me. However, for one of the iterations in which I was the product owner, the team’s estimates were low. Even when I was part of the scrum team, the estimates were low. Everyone had the expectation that they could develop each sprint backlog in relatively short time. Whereas for me, I tended to err on the side of having a little more time to account for potential risks, testing, design, and integration.

Therefore, when it was time to develop their estimations were often short (for the ones that required actually coding) as they found out there was more work than they expected, thus requiring them to do additional hours in order to complete the task. It was interesting seeing the team’s perspective prior and after and I definitely think that estimation along with features was something that looking back they would have done a little differently.

52

16. REFERENCES[1] https://mva.microsoft.com/en-us/training-courses/javascript-fundamentals-for-absolute-beginners-14194?l=DmF3TY1eB_9500115888

17. TEAM CHARTERCourse Title CPSC 544 (70) Advanced Software Process

All team members participated in the creation of this charter and agree with its content. Date 09/12/2016

Instructor Dr. Chang-Hyun Jo

Course Dates 08/22/2016 – 12/09/2016

Team Members (Contact Information)

Name Address (city, state, country) Phone Cell Email

Tou Moua Irvine, CA [email protected]

Naga Malladi Fullerton, CA (408)775 [email protected]

Kapardhi Chittella Fullerton, CA(714)-686-5329

[email protected]


Fullerton, CA [email protected]

Levi Martin Garden Grove, CA 714-925-1695 [email protected]

Nithin Reddy Gajjala

Fullerton, CA 484-300-7876 [email protected]

Tom Wang Yorba Linda, CA [email protected]

Team Member Skill Inventory (Areas individual members can contribute)

Tou Moua ▪

▪

▪

▪ Web programming, Database design and development

53

▪

▪

Naga Malladi

▪ MS Office ( Excel, Word, PowerPoint, Project, OneNote )▪ Project Management/ Product Management (JIRA, VersionOne, Microsoft Project)▪ User experience (prototyping, mockups, research, design, document)▪ Software Analysis (Requirements, Market Research, Lifecycle)▪

Kapardhi Chittella

▪

▪ Software Lifecycles (waterfall, spiral, iterative), Agile methodologies▪

▪

▪


• Programming languages: C, C++, Java, UML, Python. • Databases: SQL, MySQL.• Web Technologies: HTML, CSS, JavaScript, XML.• Java technologies: Servlets, JSP, JDBC.• Methodologies: Waterfall model, Agile model.• Applications: Eclipse, Photoshop, NetBeans, Rational Rose.

Levi Martin

▪

▪

▪ Advanced Software Process Design / Maintenance▪

Nithin Reddy Gajjala▪

▪

▪

Tom Wang

▪

▪ Project Management/ Product Management▪

▪ Software Analysis (Requirements, Market Research, Lifecycle)▪ Programming languages: C, C++, Java, UML, Python.

Team Goals (Project goals, team process goals, quality goals, etc.)

54

▪ Learn about software processes and software design and architecture.▪ Develop a strong, cohesive team and collectively produce the required assignments in a timely fashion. ▪ Acquire practical software engineering (people, process, tools, and methods) knowledge from teammates.▪ Maintain great relationship between teammates.▪ Produce and deliver a good final paper to the professor.▪ Develop skills to facilitate future career goals.

Team Roles (Define roles of each member to achieve goals)

Tou Moua

Team Lead

▪ Responsible for regular updates to team member of status of project▪ Document any tasks that need to be done with the date the team would like the task to be completed and who is responsible for each task. ▪ Moderator on team discussions

Naga Malladi

Product Owner

▪ Document the project reports and work with the scrum master and team lead to understand the progress in the project▪ Responsible for developing and adapting the product vision. ▪ Specifying the acceptance criteria of user stories and decision making ▪ Communicating with the stakeholders/program managers( Professor) regarding the project ▪ Involvement in product backlog refinement and preparation for sprint planning and participating in the retrospective after the project is ready to execute. ▪

Kapardhi Chittella

Facilitator

▪ Assist lead with the agenda before collaboration sessions.▪ Make sure collaborations sessions cover all topics outlined in the agenda w/o going over the allotted time. ▪ Make sure each teammate has a chance to provide input during the session without one dominating or one not providing any input. ▪ Remind team of their progress and ask for input.


Scrum Master

• Enabling the daily standup• Assisting the team maintain the burn down chart• Setting up retrospectives, sprint reviews or sprint planning sessions.• Defending the team from disruptions during the sprint• Removing problems that affect the team.• Helping the product owner through more technical user stories• Encouraging teamwork between the Scrum team and product owner

Levi Martin ▪ Inform teammates of any changes to the current scheduled collaborations session if collaborations sessions need to be postponed or held earlier for a

55

Scrum Team

(Scribe)

Timekeeper

particular reason.▪ Make sure team is on schedule with tasks.

Nithin Reddy Gajjala

(Developer)

▪ Helping the team to meet the deadlines.▪ Performing any task related to the development.▪ Generating the documents.

Tom Wang

▪

▪ Project Management/ Product Management▪

▪ Software Analysis (Requirements, Market Research, Lifecycle)▪ Programming languages: C, C++, Java, UML, Python.

Ground Rules (Meeting schedule/locations, attendance expectations, agenda, assignment completion, communication methods, etc.)

▪ All team members must be punctual and prepared for each team meeting.▪ Participation and input is expected from all team members. All opinions will be considered and equally valued. ▪ The team will meet at least once each week via chat or conference call to discuss current and upcoming projects or assignments (tentatively scheduled for every Wednesday @ 7pm).▪ Team members will notify the lead in advance if they are not going to be able to attend a scheduled meeting.▪ Team members should check email at least once a day to stay on top of things.▪ Team members should reply to email within 24 hours▪ Team members will turn in team assignments no later than two weeks prior to the due date.▪ All team members will be held accountable for their portions of the projects and are expected to complete them in a timely manner and doing the best job they can.▪ Notify team of emergencies that may result in not being able to meet deadlines or meetings. The rest of the team will do their best to pitch in on the team assignment.▪ Each semester, a different person will be nominated to lead the team. ▪ The team must maintain open, clear, and effective communication at all times.▪ Assist fellow team members when they are in need. ▪ Maintain a positive, honest, and open atmosphere by respecting other members’ suggestions, using constructive criticism, and encouragement. ▪ No plagiarism. Every member must be responsible to avoid/prevent plagiarism. (How to?)

Time Commitments/Availability (Pacific Time)

Tou Moua ▪ T&Th, 5pm-9pm (can make other arrangements as necessary)▪ Saturday, 12pm – 3pm

56

Naga Malladi ▪ T&Th 3pm-10pm▪ Saturday, 12pm-9pm, Sunday 9am- 9pm

Kapardhi Chittella▪ M, W & F 8am - 12pm Tu & Th 9am-1pm Sun 2pm - 9pm

Ram Anudeep Kuchibhotla ▪ M-F, 7-12am (can make arrangements if meeting earlier is necessary)▪ Saturday & Sunday, all day

Levi Martin ▪▪ Saturday, All Day After Shared “Modern Software Management” Class

Nithin Reddy Gajjala▪▪

Tom Wang▪▪ Saturday, All Day After Shared “Modern Software Management” Class

Conflict Management (What are potential conflicts that might arise among or between team members during this course? How will team members deal with these and other conflicts?)

▪ In order to avoid conflict clear roles and responsibilities must be assigned, so that there is no confusion. ▪ If a team member is not performing, the team lead will speak to the member and try and resolve the issue.▪ If conflicts arise, please bring them up to the whole team so that everybody can help to resolve the issue in a peaceful and harmonious manner.▪ All team members must settle conflicts within the group as quickly as possible.

Risk Management (What are potential barriers to the achievement of these goals?)▪ Potential risk include inability to meet due to conflicting schedules▪ Risk mitigation plan is to schedule meeting dates a week before to allow ample time to communicate▪ If risk becomes critical, then team meetings will be scheduled over video conference or virtually

▪ Potential risk include family problems that may arise▪ Risk mitigation plan is to have another team member fill in for missing team member and update missing

team member once they are back ▪ If risk is critical, notify appropriate party that team member is unable to contribute and continue with

project due to family issues

Team Evaluation Criteria (List evaluation criteria that will be used to evaluate team members objectively.)

57

▪ Evaluate objectively by objective evidence as defined here (e.g., team meeting log, documents, email record, etc.), not by subjective opinions. ▪ Completion of assigned items▪▪ Team meeting logs

18. TEAM EVALUATION

58

Date post:	10-Feb-2017
Category:	Documents
Upload:	anudeep-kuchibhotla
View:	51 times
Download:	4 times

CPSC_544_HWK_1_FINAL (1)

Documents