From fd98a494ddcc805faa560357e111453dedc03034 Mon Sep 17 00:00:00 2001 From: teresa-Guilherme Date: Wed, 12 Oct 2016 11:26:39 +0100 Subject: [PATCH 01/11] Update Assignment 1.md process description #1 --- ESOF-docs/Assignment 1.md | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/ESOF-docs/Assignment 1.md b/ESOF-docs/Assignment 1.md index 7a8fd7f65..cacf8116d 100644 --- a/ESOF-docs/Assignment 1.md +++ b/ESOF-docs/Assignment 1.md @@ -6,14 +6,8 @@ As described in the Read Me file, Citra is an open-source and passion driven Nin **Development Process** -Incremental development and delivery -• Develop the system in increments and evaluate each -increment before proceeding to the development of the -next increment -• Evaluation done by user/customer proxy -• Some of the increments can be deployed to end-users -• The waterfall model can be followed in each increment -• Normal approach used in agile methods +>Citra is being developed as an hobby for several programmers and their work schedule on this Open Source Software Project is not very consistent. They are not supported by any company, therefore they don't have a deadline to implement features. Citra has a team of experiences developers that help (begginer/intermediate level) new contributtors with the standard level of code that is to be commited. They take a while to accept pull requests, so that they are certain that the pull has the quality they require, in order to avoid bugs or setbacks. + >Since the contributes frequency is inconsistent, they can't use any industrial-standard engeneering process. They "are constantly working on new features" (said by one of the project leaders) so it would be considered an Incremental development process. However as they don´t have any kind of deadlines and they only merge when they are sure the feature is operating correctly, we think they are also using a Slow programming process. **Opinions, Critics and Alternatives** From 8f9b0f2df8c794f763e4d789359478d1b91aa97e Mon Sep 17 00:00:00 2001 From: PORShoterxx Date: Sat, 15 Oct 2016 18:51:33 +0100 Subject: [PATCH 02/11] Added Opinions, Critics and Alternatives --- ESOF-docs/Assignment 1.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/ESOF-docs/Assignment 1.md b/ESOF-docs/Assignment 1.md index cacf8116d..f88c8399b 100644 --- a/ESOF-docs/Assignment 1.md +++ b/ESOF-docs/Assignment 1.md @@ -1,14 +1,24 @@ **Brief description of the project** -As described in the Read Me file, Citra is an open-source and passion driven Nintendo 3DS emulator/debugger written in C++ is written so builds can be actively maintained for Windows, Linux and OS X. At this time, Citra is able to boot many commercial games, most of which do not run to a playable state yet, but are being worked on every day to advance the project forward. +As described in the README.md file, Citra is an open-source, passion-driven Nintendo 3DS emulator/debugger written in C++ is written so builds can be actively maintained for Windows, Linux and OS X. At this time, Citra is able to boot many commercial games, most of which do not run to a playable state yet, but are being worked on every day to advance the project forward. **Development Process** ->Citra is being developed as an hobby for several programmers and their work schedule on this Open Source Software Project is not very consistent. They are not supported by any company, therefore they don't have a deadline to implement features. Citra has a team of experiences developers that help (begginer/intermediate level) new contributtors with the standard level of code that is to be commited. They take a while to accept pull requests, so that they are certain that the pull has the quality they require, in order to avoid bugs or setbacks. - >Since the contributes frequency is inconsistent, they can't use any industrial-standard engeneering process. They "are constantly working on new features" (said by one of the project leaders) so it would be considered an Incremental development process. However as they don´t have any kind of deadlines and they only merge when they are sure the feature is operating correctly, we think they are also using a Slow programming process. +>Citra is being developed as a hobby for several programmers and their work schedule on this Open Source Software Project is not very consistent. They are not supported by any company, therefore they don't have a deadline to implement features. Citra has a team of experiences developers that help (begginer/intermediate level) new contributors with the standard level of code that is to be commited. They take a while to accept pull requests, so that they are certain that the pull has the quality they require, in order to avoid bugs or setbacks. + >Since the contribution frequency is inconsistent, they can't use any industrial-standard engineering process. They "are constantly working on new features" (as said by one of the project leaders) so it would be considered an Incremental development process. However, as they don´t have any kind of deadlines and they only merge when they are sure the feature is operating correctly, we think they are also using a Slow programming process. **Opinions, Critics and Alternatives** +- Due to how they work, the Incremental Development and Deployment process is the most reliable, if not the only plausible, development process. +- Test-driven development is an alternative to the above. However, this is ill-advised. As with an emulator's nature, it's required to work with multiple games, each with it's own code quirks, while optimizing for playable perfomance. This would mean an excessive amount of tests, and very slow progress towards an acceptable result. + +- Being a hobby project, there's no fixed planning in development. Most releases tend to be random bug fixes, small new features, etc. +- There is a guideline on code style. This improves feature recognition by other developers and smoothens development times. +- Since it's an open project, it's bound to have disparities in coding methodology. This issue has been actively tackled, just as explained above. +- Having a stricter group of developers would potentialy hurt development times, and not necessarily improve code quality, since pull requests are already verified individually before merge. + +- As a result of its early development stage, the interface is not very user-friendly and there's a large ammount of bugs. +- Part of this project requires specific knowledge about console hardware, emulation, among other areas. This significantly decreases the quantity of code submissions. From 33e3c2092196e7571ed15af5bacddf6f8b2104a0 Mon Sep 17 00:00:00 2001 From: teresa-Guilherme Date: Sun, 16 Oct 2016 13:02:59 +0100 Subject: [PATCH 03/11] Update Assignment 1.md MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit organização das **Opinions, Critics and Alternatives** --- ESOF-docs/Assignment 1.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/ESOF-docs/Assignment 1.md b/ESOF-docs/Assignment 1.md index f88c8399b..830394054 100644 --- a/ESOF-docs/Assignment 1.md +++ b/ESOF-docs/Assignment 1.md @@ -1,24 +1,24 @@ **Brief description of the project** -As described in the README.md file, Citra is an open-source, passion-driven Nintendo 3DS emulator/debugger written in C++ is written so builds can be actively maintained for Windows, Linux and OS X. At this time, Citra is able to boot many commercial games, most of which do not run to a playable state yet, but are being worked on every day to advance the project forward. + As described in the README.md file, Citra is an open-source, passion-driven Nintendo 3DS emulator/debugger written in C++ is written so builds can be actively maintained for Windows, Linux and OS X. At this time, Citra is able to boot many commercial games, most of which do not run to a playable state yet, but are being worked on every day to advance the project forward. **Development Process** ->Citra is being developed as a hobby for several programmers and their work schedule on this Open Source Software Project is not very consistent. They are not supported by any company, therefore they don't have a deadline to implement features. Citra has a team of experiences developers that help (begginer/intermediate level) new contributors with the standard level of code that is to be commited. They take a while to accept pull requests, so that they are certain that the pull has the quality they require, in order to avoid bugs or setbacks. - >Since the contribution frequency is inconsistent, they can't use any industrial-standard engineering process. They "are constantly working on new features" (as said by one of the project leaders) so it would be considered an Incremental development process. However, as they don´t have any kind of deadlines and they only merge when they are sure the feature is operating correctly, we think they are also using a Slow programming process. - + Citra is being developed as a hobby for several programmers and their work schedule on this Open Source Software Project is not very consistent. They are not supported by any company, therefore they don't have a deadline to implement features. Citra has a team of experiences developers that help (begginer/intermediate level) new contributors with the standard level of code that is to be commited. They take a while to accept pull requests, so that they are certain that the pull has the quality they require, in order to avoid bugs or setbacks. + Since the contribution frequency is inconsistent, they can't use any industrial-standard engineering process. They "are constantly working on new features" (as said by one of the project leaders) so it would be considered an Incremental development process. However, as they don´t have any kind of deadlines and they only merge when they are sure the feature is operating correctly, we think they are also using a Slow programming process. + They also use test driven development for certain parts of the emulator, but they fear that making the project only based on test driven, would scare the contributtors with the amounts of bureaucracy needed to implemented. **Opinions, Critics and Alternatives** -- Due to how they work, the Incremental Development and Deployment process is the most reliable, if not the only plausible, development process. -- Test-driven development is an alternative to the above. However, this is ill-advised. As with an emulator's nature, it's required to work with multiple games, each with it's own code quirks, while optimizing for playable perfomance. This would mean an excessive amount of tests, and very slow progress towards an acceptable result. - -- Being a hobby project, there's no fixed planning in development. Most releases tend to be random bug fixes, small new features, etc. -- There is a guideline on code style. This improves feature recognition by other developers and smoothens development times. -- Since it's an open project, it's bound to have disparities in coding methodology. This issue has been actively tackled, just as explained above. -- Having a stricter group of developers would potentialy hurt development times, and not necessarily improve code quality, since pull requests are already verified individually before merge. - -- As a result of its early development stage, the interface is not very user-friendly and there's a large ammount of bugs. -- Part of this project requires specific knowledge about console hardware, emulation, among other areas. This significantly decreases the quantity of code submissions. + The use of incremental development and delivery as an engineer process, has its advantages, such as: + * more interaction between the users/client and developers and consequently, early and requent feedback from the client; + * low chance of project failure; + * the most important requirement is tested thoroughly; + + This process provides a more closely and frequently interaction to meet the client's needs. On the other hand the main disadvantage, and the one we consider that might eventually occurr is code degradation. Using this process may degrade the quality of the code, as it is harder to refractor as more features are implemented. + Given the circunstances of this project (hobby, volunteers, low amount of time that developers have to work and inconsistent frequency of commits,specific knowledge about console hardware, emulation, among other areas), we would say that Incremental Development and Deployment process is the most reliable, if not the only plausible development process. + Test-driven development is an alternative to the above. However, this is ill-advised. As with an emulator's nature, it's required to work with multiple games, each with it's own code quirks, while optimizing for playable perfomance. This would mean an excessive amount of tests, and very slow progress towards an acceptable result. + Since it's an open project, it's bound to have disparities in coding methodology. However, there is a guideline on code style. This improves feature recognition by other developers and smoothens development times. + There is a guideline on code style. This improves feature recognition by other developers and smoothens development times. Having a stricter group of developers would potentialy hurt development times, and not necessarily improve code quality, since pull requests are already verified individually before merge. From cef3e0233b6abce359e4de8a6a55bf274334ab56 Mon Sep 17 00:00:00 2001 From: teresa-Guilherme Date: Sun, 16 Oct 2016 22:11:33 +0100 Subject: [PATCH 04/11] Update Assignment 1.md --- ESOF-docs/Assignment 1.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/ESOF-docs/Assignment 1.md b/ESOF-docs/Assignment 1.md index 830394054..f8527343e 100644 --- a/ESOF-docs/Assignment 1.md +++ b/ESOF-docs/Assignment 1.md @@ -7,7 +7,9 @@ **Development Process** Citra is being developed as a hobby for several programmers and their work schedule on this Open Source Software Project is not very consistent. They are not supported by any company, therefore they don't have a deadline to implement features. Citra has a team of experiences developers that help (begginer/intermediate level) new contributors with the standard level of code that is to be commited. They take a while to accept pull requests, so that they are certain that the pull has the quality they require, in order to avoid bugs or setbacks. + Since the contribution frequency is inconsistent, they can't use any industrial-standard engineering process. They "are constantly working on new features" (as said by one of the project leaders) so it would be considered an Incremental development process. However, as they don´t have any kind of deadlines and they only merge when they are sure the feature is operating correctly, we think they are also using a Slow programming process. + They also use test driven development for certain parts of the emulator, but they fear that making the project only based on test driven, would scare the contributtors with the amounts of bureaucracy needed to implemented. **Opinions, Critics and Alternatives** @@ -18,7 +20,11 @@ * the most important requirement is tested thoroughly; This process provides a more closely and frequently interaction to meet the client's needs. On the other hand the main disadvantage, and the one we consider that might eventually occurr is code degradation. Using this process may degrade the quality of the code, as it is harder to refractor as more features are implemented. + Given the circunstances of this project (hobby, volunteers, low amount of time that developers have to work and inconsistent frequency of commits,specific knowledge about console hardware, emulation, among other areas), we would say that Incremental Development and Deployment process is the most reliable, if not the only plausible development process. + Test-driven development is an alternative to the above. However, this is ill-advised. As with an emulator's nature, it's required to work with multiple games, each with it's own code quirks, while optimizing for playable perfomance. This would mean an excessive amount of tests, and very slow progress towards an acceptable result. + Since it's an open project, it's bound to have disparities in coding methodology. However, there is a guideline on code style. This improves feature recognition by other developers and smoothens development times. + There is a guideline on code style. This improves feature recognition by other developers and smoothens development times. Having a stricter group of developers would potentialy hurt development times, and not necessarily improve code quality, since pull requests are already verified individually before merge. From 82b7c6a63e01a98dfb2dcabec7454e6cc3f6d74d Mon Sep 17 00:00:00 2001 From: ruimoliveira Date: Wed, 19 Oct 2016 10:20:00 +0100 Subject: [PATCH 05/11] Create Assignment 2.md --- ESOF-docs/Assignment 2.md | 9 +++++++++ 1 file changed, 9 insertions(+) create mode 100644 ESOF-docs/Assignment 2.md diff --git a/ESOF-docs/Assignment 2.md b/ESOF-docs/Assignment 2.md new file mode 100644 index 000000000..e0bfcc3fe --- /dev/null +++ b/ESOF-docs/Assignment 2.md @@ -0,0 +1,9 @@ +>Requirements: Introduction, Purpose/Scope, and Description +>>Grade: 3pts +>>Note: This is a generic introduction to requirements as well as requirements elicitation in the project (how is this done? How does the team decides on whether to implement a new features, etc. ) +>Specific Requirements and Features (Functional and Non-Functional requirements) +>>Grade: 5pts +>Use Cases (including diagrams) +>>Grade: 6pts +>Domain Model +>>Grade: 6 pts From 5c5a4ffa3c9d8268fb79dee381b5c0f57a51c256 Mon Sep 17 00:00:00 2001 From: ruimoliveira Date: Wed, 19 Oct 2016 10:21:06 +0100 Subject: [PATCH 06/11] Update Assignment 2.md --- ESOF-docs/Assignment 2.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ESOF-docs/Assignment 2.md b/ESOF-docs/Assignment 2.md index e0bfcc3fe..1c13c4198 100644 --- a/ESOF-docs/Assignment 2.md +++ b/ESOF-docs/Assignment 2.md @@ -1,9 +1,12 @@ >Requirements: Introduction, Purpose/Scope, and Description >>Grade: 3pts >>Note: This is a generic introduction to requirements as well as requirements elicitation in the project (how is this done? How does the team decides on whether to implement a new features, etc. ) + >Specific Requirements and Features (Functional and Non-Functional requirements) >>Grade: 5pts + >Use Cases (including diagrams) >>Grade: 6pts + >Domain Model >>Grade: 6 pts From 3a0ba3555b8732ff3787d49a5f8cc84ea382190e Mon Sep 17 00:00:00 2001 From: ruimoliveira Date: Wed, 19 Oct 2016 10:22:00 +0100 Subject: [PATCH 07/11] Update Assignment 2.md --- ESOF-docs/Assignment 2.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/ESOF-docs/Assignment 2.md b/ESOF-docs/Assignment 2.md index 1c13c4198..f76176b9c 100644 --- a/ESOF-docs/Assignment 2.md +++ b/ESOF-docs/Assignment 2.md @@ -1,12 +1,13 @@ ->Requirements: Introduction, Purpose/Scope, and Description ->>Grade: 3pts ->>Note: This is a generic introduction to requirements as well as requirements elicitation in the project (how is this done? How does the team decides on whether to implement a new features, etc. ) +Requirements: Introduction, Purpose/Scope, and Description +>Grade: 3pts ->Specific Requirements and Features (Functional and Non-Functional requirements) ->>Grade: 5pts +>Note: This is a generic introduction to requirements as well as requirements elicitation in the project (how is this done? How does the team decides on whether to implement a new features, etc. ) ->Use Cases (including diagrams) ->>Grade: 6pts +Specific Requirements and Features (Functional and Non-Functional requirements) +>Grade: 5pts ->Domain Model ->>Grade: 6 pts +Use Cases (including diagrams) +>Grade: 6pts + +Domain Model +>Grade: 6 pts From 86a31c32e8c8bf023ef024d9317185bc026443e8 Mon Sep 17 00:00:00 2001 From: ruimoliveira Date: Wed, 26 Oct 2016 11:32:18 +0100 Subject: [PATCH 08/11] Update Assignment 2.md --- ESOF-docs/Assignment 2.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ESOF-docs/Assignment 2.md b/ESOF-docs/Assignment 2.md index f76176b9c..52012ba40 100644 --- a/ESOF-docs/Assignment 2.md +++ b/ESOF-docs/Assignment 2.md @@ -7,7 +7,9 @@ Specific Requirements and Features (Functional and Non-Functional requirements) >Grade: 5pts Use Cases (including diagrams) ->Grade: 6pts +These are the uses we could figure out for both the application. +![alt tag](http://i.imgur.com/deDgtE4.png) Domain Model >Grade: 6 pts + From 1852ff1d9ab1487ee0fee15c4b3f9173031bcae4 Mon Sep 17 00:00:00 2001 From: ruimoliveira Date: Wed, 26 Oct 2016 11:33:13 +0100 Subject: [PATCH 09/11] Update Assignment 2.md --- ESOF-docs/Assignment 2.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ESOF-docs/Assignment 2.md b/ESOF-docs/Assignment 2.md index 52012ba40..17d39b47e 100644 --- a/ESOF-docs/Assignment 2.md +++ b/ESOF-docs/Assignment 2.md @@ -6,7 +6,8 @@ Requirements: Introduction, Purpose/Scope, and Description Specific Requirements and Features (Functional and Non-Functional requirements) >Grade: 5pts -Use Cases (including diagrams) +**Use Cases** + These are the uses we could figure out for both the application. ![alt tag](http://i.imgur.com/deDgtE4.png) From c79ceffbc63cb60e916470894fef75fabd568feb Mon Sep 17 00:00:00 2001 From: pedrof81 Date: Sat, 29 Oct 2016 11:31:48 +0100 Subject: [PATCH 10/11] Update Assignment 2 Requirements: Introduction, Purpose/Scope, and Description --- ESOF-docs/Assignment 2.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/ESOF-docs/Assignment 2.md b/ESOF-docs/Assignment 2.md index 17d39b47e..8cae31579 100644 --- a/ESOF-docs/Assignment 2.md +++ b/ESOF-docs/Assignment 2.md @@ -1,8 +1,15 @@ Requirements: Introduction, Purpose/Scope, and Description >Grade: 3pts - >Note: This is a generic introduction to requirements as well as requirements elicitation in the project (how is this done? How does the team decides on whether to implement a new features, etc. ) +Before we can start building a project it is essential that the team study the costumers and user needs so the team can have a clear statement and understanding of required properties of a solution to solve the problem. +The requirements for a system are the descriptions of what the system should do, the services that it provides and the constraints on its operation.Some of the problems that arise during the requirements engineering process are a result of failing to make a clear separation between these different levels of description. +We can divide them in two: user requirements and system requirements. +User requirements are statements of what services of the system is expected to provide to system users and the constraints under which it must operate. + +(Not Finished) + + Specific Requirements and Features (Functional and Non-Functional requirements) >Grade: 5pts From dad2b408b185f788ec69fdbf6c867c439c5d9b6a Mon Sep 17 00:00:00 2001 From: pedrof81 Date: Sat, 29 Oct 2016 14:26:04 +0100 Subject: [PATCH 11/11] Update Assignment 2 Introduction Requirements-Introduction 2 --- ESOF-docs/Assignment 2.md | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/ESOF-docs/Assignment 2.md b/ESOF-docs/Assignment 2.md index 8cae31579..902740e98 100644 --- a/ESOF-docs/Assignment 2.md +++ b/ESOF-docs/Assignment 2.md @@ -1,15 +1,30 @@ -Requirements: Introduction, Purpose/Scope, and Description ->Grade: 3pts ->Note: This is a generic introduction to requirements as well as requirements elicitation in the project (how is this done? How does the team decides on whether to implement a new features, etc. ) + +**Requirements** Before we can start building a project it is essential that the team study the costumers and user needs so the team can have a clear statement and understanding of required properties of a solution to solve the problem. The requirements for a system are the descriptions of what the system should do, the services that it provides and the constraints on its operation.Some of the problems that arise during the requirements engineering process are a result of failing to make a clear separation between these different levels of description. We can divide them in two: user requirements and system requirements. + User requirements are statements of what services of the system is expected to provide to system users and the constraints under which it must operate. +System requirements are more detailed descriptions of the software system’s functions, services, and operational constraints. -(Not Finished) +Software system requirements are often classified as functional requirements or non-functional requirements. +Citra requires a 64-bit processor and OpenGl3.3 in order to emulate the 3DS. +The functional requirements for a system describe what the system should do. +Non-functional requirements, as the name suggests, are requirements that are not directly concerned with the specific services delivered by the system to its users. + +Requirement engineering processes may include four important high-level activities. These focus on assessing if the system is useful to the business (feasibility study), discovering requirements (elicitation and analysis), converting these requirements into some standard form (specification), and checking that the requirements actually define the system that the customer wants (validation). + +Since Citra is not supported by any company they don't have a deadline to implement features, so how does the team decide on whether to implement a new feature or no? They implement features when they want or when the contributors have a feature that have the quality they require in order to avoid bugs or setbacks +For requirements elicitation we informal interview the developers and discover their requirements in their project site https://citra-emu.org/. + +Their main focus right now is to fix bugs that stop games from booting and bugs that crashes the program when running. While issues about specific games not booting are valid bugs, they are currently not interested in them unless there are several games which fail with the same or similar messages. There are too many non-working games right now to file individual issues for every one of them. +In future with low priority they intend to implement features like cheat code support, improve speed of cut scenes and support for smartphones, but right now, the main focus is getting the PC port stable. +Given the circumstances of this project (hobby, volunteers, low amount of time that developers have to work and inconsistent frequency of commits, specific knowledge about console hardware, emulation, among other areas) the reality of the new features is contributors of Citra contribute what they like and not always what is ideal. + +** Specific Requirements and Features ** Specific Requirements and Features (Functional and Non-Functional requirements) >Grade: 5pts