CSI 3370 Software Process and Project Management.

Please see Assignment1.pdf file in the zipped folder. I have also provided the lecture notes material from class just in case it may help the assigned expert if he/she were to be unsure on any part of the assignment. The provided lecture notes should contain all the information needed to complete this homework assignment.

Assignment 1: Software Process and Project Management
CSI 3370
Student’s name
Institution Affiliation(s)

Q1. Discuss the differences between the Spiral model and the Unified Process model.
The spiral model is the most generic model. Mostly all the other models are usually
special cases of this model. The way that he spiral model approaches software development is a
risk management approach. There are many advantages to doing this. One advantage is that it
uses the same approach for both the development and the maintenance. Another advantage is that
it focuses early on error detection and design problems (Ray, 2013). The last advantage of this
model is that estimating the cost becomes easy because prototype building is done in small
fragments. This gives the customer control over the system. Some disadvantages of using this
model are that this model works best, usually on large projects where the costs are high. Another
disadvantage is that evaluating the risks involved in the project can increase the cost by a lot and
sometimes even can be more expensive than the cost of building the system.
In contrast, the Unified process model is a software development methodology that is
incremental, architecture-centric, use case driven, and interactive in its approach. Being an
interactive and an incremental method means that this approach takes each iteration as a mini-
project and therefore, a given project is divided into small mini-projects and then completed and
added up to complete the whole project. The unified process model has four phases, including
inception, elaboration, construction and transition (Fang & Liu, 2011). The inception phase is
where an analyst collects the requirements from the client while analyzing the project's profits,
cost, time and feasibility. The elaboration stage helps in creating use cases and detailed
architecture that will enable the realization of the requirements gathered at the inception stage.
The construction stage involves programming and the actual implementation of each iteration
and finally, the transitions stage is where the project is rolled out to the customer and the fixing
of bugs.

Q2.
(i) Agile Project Plan
Develop a backlog. A backlog is a prioritized list of requirements, that is, user stories and
features. In a backlog, items can be added at any time as scrum methodology adapts to changes.
A sprint is a work unit meant to achieve one backlog item and its time-box is about 30 days.
During the sprint, all the affected backlogs items are frozen and short scrum meetings are held
for about 15 minutes every day, where what was done since the last meeting, the obstacles
encountered, and what will be done by the next meeting is discussed. Demos are used in scrum
methodology to deliver software increments to the customer for evaluation (Madampe, 2017).
(ii) An Agile Test Plan
The agile development methodology is where work is done in short sprints or iterations with
each sprint focusing on only a few user stories or few requirements. Thus, it is critical to come
up with a test strategy so that the code can be tested after every user story is complete (Stare,
2014).
The agile test plan includes the types of testing that are done in each iteration. These
activities include testing the data requirements, testing the system environment, testing the
results of the system and testing the infrastructure (Khan & Srivastava, 2016). Other activities
including testing the scope of the system, testing each and every new functionality that is added
to the system, the levels of testing based on the complexity of features, load and performance
testing, risk planning and mitigation, and time and cost estimation are also included in the test
plans.
Firstly, the team needs to come up with an agile test strategy.
Agile Test Strategy

Iteration 0
At the initial stage, tasks are setup including identifying the persons that will be responsible
for testing, scheduling resources and installing the tools that will be used for testing. It is at this
stage that the risks will be identified, cost estimation done, and preliminary project repaired.
Also, this stage identifies the critical requirements and comes up with the use cases that will
determine the design tradeoffs (Tyagi & Sibal, 2017). The project scope and the business case
are also established at this stage.
Construction iteration
The majority of the testing happens at the construction iterations. With each iteration, the
agile team implements a hybrid of practices, including scrum and agile modeling using a
prioritized requirement approach. The most critical requirements remaining from the previous
iteration are stack and implemented at this stage (Awotar & Sungkur, 2018).
This stage father involves two types of testing, that is, confirmatory testing and investigative
testing. Confirmatory testing is done so that the team can verify that the system has fulfilled the
customer's requirement as described to them at the current iteration. The confirmatory testing is
further subdivided into two types of testing, that is, developer testing and acceptance testing.
Acceptance testing is a combination of both traditional functional testing and acceptance testing
as the team carries out this testing together with all the stakeholders (Basit & Flahaven, 2018).

On the other hand, developer testing is a mix of unit testing and service integration testing where
both the code and the database schema are verified. Investigative testing detects any problem that
the confirmatory agile team may have skipped or ignored. Investigative testing includes
integration testing, stress testing, security testing and other types of testing to determine the
potential problems in any form of defect that might arise while the system is working (Ganesh &
Thangasamy, 2012).
The transition phase
The transition phase is aimed at deploying the system successfully into production. Activities
that are carried out in this phase include training the end-users, supporting the users and the
operational people. At this stage marketing of the product release, backup and restore points and
user documentation are developed (Nerur & Balijepally, 2012).
Production phase
This is the final stage after the transition phase, where the product is produced. It is important
to note that in scrum and agile methodology quality assurance is responsible for every member
of the team and is not only left to the testers (Mariani & Subramanyan, 2017). Quality assurance
activities include the correct quality during the development of a new product. In the described
case scenario, the agile testing that will be done will include unit testing, service testing and
acceptance testing (Hidalgo, 2019).
Unit Testing
WHO Developers / Technical Architects, i.e. Emily
WHY To ensure code is developed correctly
WHAT All new code + refactoring of legacy code as well as Javascript unit Testing
WHEN As soon as the new code is written
WHERE Local Dev + CI (part of the build)

HOW Automated, Junit, TestNG, PHPUnit
Service Testing
WHO Developers / Technical Architects, i.e. Chris
WHY To ensure communication between components are working
WHAT New web services, components, controllers, etc
WHEN As soon as a new API is developed and ready
WHERE Local Dev + CI (part of the build)
HOW Automated, Soap UI, Rest Client
Acceptance Testing
WHO Developer / SDET / Manual QA, i.e. Myself, Jon, Chris, and Emily
WHY To ensure customer’s expectations are met
WHAT Verifying acceptance tests on the stories, verification of features
WHEN When the feature is ready, and unit tested
WHERE CI / Test Environment
HOW Automated
Product backlog
A product backlog is a list of all system features ordered by priority where features in the
backlog have an estimate of effort. The client, in conjunction with the agile team, starts by
outlining everything they think needs agile product backlog prioritization. The first product
backlog that is developed for the first sprint is usually enough for the whole project as it is then

allowed to grow and change with respect to the changing needs of the product and its clients. A
typical agile backlog may comprise items such as features, bugs, technical work, and knowledge
acquisition (Wagenaar & Schneider, 2018). The most common way that an agile team uses to
express features in a backlog is by the use of user stories which are short and simple descriptions
that explain the functionality of the system from a user's perspective. In an agile product backlog,
a bug and a new feature both describe something different that a user wants. Technical work and
knowledge acquisition such as upgrading developer workstations to a newer version of the
operating system are also included in a product backlog. The client or the product owner is
included in the sprint meetings that are regularly held so that they can help in describing the
priority of items that have been included in a product backlog (Perkusich & Silva, 2017).

Low priority features can be removed at any time. Medium priority features may be reprioritized
at any time while a new feature is prioritized and added to the above stack.
User Stories
1. As a Developer, Emily wants the information system, So that the system allows users to
view information about the tours available and make a reservation on tour without asking
the employees at the agency.
2. As a Developer, Jon wants the information system, So that a user can cancel an existing
reservation that the user made.
3. As a Developer, I myself want the database system, So that the system allows a user to
send feedback by email to the agency and stores the feedback in the database.
4. As a Developer, Chris wants the information system, So that the system allows the
employees of the agency to manage customers and tours such as adding, deleting, and
updating information on customers and tours.

Q3.
Cost estimation is done using Function Point (FP). The function point is then converted
to a line of Code (LoC) which is then compared with the past data (Yadav & Sharma, 2018).
Functional point analysis determines the project size based on the functional requirements in two
steps; by first performing the counts and then estimating the efforts. Performing the count is done
into two steps where data functions are counted and then the transaction functions are counted.
The data functions include internal logical files and external interface files while the transaction
functions include the external input, external output and finally, the external queries (Putri &
Subriadi, 2019). While computing the estimated effort, the following procedure is used
(i) First, compute the unadjusted function points (UFP) using the below formula
UFP = a · EI + b · EO + c · EQ + d · ILF + e · EIF where a – e are weight factors, then
(ii) Compute the value-added factor (VAF)
(iii) Compute the adjusted function points (AFP)
(iv) Computer performance factor (PF), and finally,
(v) Calculate the effort in person-days
Mapping Functions to Transaction Types
(i) External Inputs (EI) – Open Switch, Close Switch, Emergency button
(ii) External Outputs (EO) – Message, Light signal, Emergency signal.
(iii) External Queries (EQ) – Gate Inquiry
(iv) Internal Logical Files (ILF) – Gate, Switches, Emergency
(v) External Interface Files (EIF) – Emergency alert, Gate open, gate close
Calculate the Unadjusted Function Points (UFP)
Function Type Weight Factors

Number Simple Average Complex
External Inputs (EI) 3 x 3 4 6 = 9
External Outputs (EO) 3 x 4 5 7 = 12
External Queries (EQ) 1 x 3 4 6 = 3
Internal Logical Files (ILF) 3 x 7 10 15 = 21
External Interface Files
(EIF)
3 x 5 7 10 = 15
Unadjusted Function Points (UFP) = 60
General System Complexity Factors (GSC)
These are factors to adjust the functional points where each factor is assigned a value between 0
and 5.
GSC1 Reliable Backup & Recovery (2)
GSC2 Use of Data Communication (3)
GSC3 Use of Distributed Computing (1)
GSC4 Performance (2)
GSC5 Realization in heavily used configuration (2)
GSC6 On-line data entry (2)
GSC7 User Friendliness (1)
GSC8 On-line data change (3)
GSC9 Complex user interface (1)
GSC10 Complex procedures (3)
GSC11 Reuse (1)
GSC12 Ease of installation (2)

GSC13 Use at multiple sites (1)
GSC14 Adaptability and flexibility (3)
Calculating Efforts
- Compute Value Added Factor (VAF) with GSC factors
VAF=0.65+0.01∗∑
i=1
14
( GSCi )
Where GSCi=0 ,1 , ..5
VAF = 0.65 + 0.01 * 27 = 0.92
Adjusted Function Points (AFP)
AFP = UFP * AVF
= 60*0.92
=55.2
Estimate Efforts
(i) Performance Factor (PF): number of lines of code (LoC) per function point based on
historical data.
Project Size = AFP * PF
Assuming PF = 50, then
Effort = 60 * 50
= 3000 LoC
(ii) Performance Factor (PF): Number of function points that can be completed per day
based on historical data.
Effort = AFP / PF

Assuming PF = 2, then
Effort = 55.2/2 = 27.6 days

References
Awotar, M., & Sungkur, R. K. (2018). Optimization of Software Testing. Procedia Computer
Science, 132, 1804–1814. https://doi.org/10.1016/j.procs.2018.05.142
Basit, M. A., & Flahaven, E. L. (2018). Agile Acceptance Test–Driven Development of Clinical
Decision Support Advisories: Feasibility of Using Open Source Software. JMIR Medical
Informatics, 6(2). https://doi.org/10.2196/medinform.9679
Fang, H. G., & Liu, M. (2011). Research on Educational Software Unified Process Model Based
on Education Domain Knowledge. Advanced Materials Research, 271–273, 1279–1285.
https://doi.org/10.4028/www.scientific.net/AMR.271-273.1279
Ganesh, N., & Thangasamy, S. (2012). New Agile Testing Modes. Information Technology
Journal, 11(6), 707–712. https://doi.org/10.3923/itj.2012.707.712
Hidalgo, E. S. (2019). Adapting the scrum framework for agile project management in science:
Case study of a distributed research initiative. Heliyon, 5(3), e01447.
https://doi.org/10.1016/j.heliyon.2019.e01447
Khan, R., & Srivastava, A. (2016). Agile approach for Software Testing process. 3–6.
https://doi.org/10.1109/SYSMART.2016.7894479
Madampe, K. (2017). Successful Adoption of Agile Project Management in Software
Development Industry. International Journal of Computer Science and Information
Technology Research, 5, 27–33.
Mariani, L., & Subramanyan, R. (2017). The central role of test automation in software quality
assurance. Software Quality Journal, 25(3), 797–802. https://doi.org/10.1007/s11219-
017-9383-5

Nerur, S., & Balijepally, V. (2012). A decade of agile methodologies: Towards explaining agile
software development. Journal of Systems and Software, 85(6), 1213–1221.
https://doi.org/10.1016/j.jss.2012.02.033
Perkusich, M., & Silva, A. (2017, July 5). Ordering the Product Backlog in Agile Software
Development Projects: A Systematic Literature Review.
https://doi.org/10.18293/SEKE2017-007
Putri, A. Y. P., & Subriadi, A. P. (2019). Software Cost Estimation Using Function Point
Analysis. IPTEK Journal of Proceedings Series, 0(1), 79-83–83.
https://doi.org/10.12962/j23546026.y2019i1.5115
Ray, L. L. (2013). Security considerations for the spiral development model. International
Journal of Information Management, 33(4), 684–686.
https://doi.org/10.1016/j.ijinfomgt.2013.03.003
Stare, A. (2014). Agile Project Management in Product Development Projects. Procedia - Social
and Behavioral Sciences, 119, 295–304. https://doi.org/10.1016/j.sbspro.2014.03.034
Tyagi, S., & Sibal, R. (2017). Adopting Test Automation on Agile Development Projects: A
Grounded Theory Study of Indian Software Organizations. In H. Baumeister, H. Lichter,
& M. Riebisch (Eds.), Agile Processes in Software Engineering and Extreme
Programming (pp. 184–198). Springer International Publishing.
https://doi.org/10.1007/978-3-319-57633-6_12
Wagenaar, G., & Schneider, K. (2018). Working software over comprehensive documentation –
Rationales of agile teams for artefacts usage. Journal of Software Engineering Research
and Development, 6(1), 7. https://doi.org/10.1186/s40411-018-0051-7

Yadav, A., & Sharma, A. (2018). Function Point Based Estimation of Effort and Cost in Agile
Software Development (SSRN Scholarly Paper ID 3171528). Social Science Research
Network. https://papers.ssrn.com/abstract=3171528