SOLVED CS605 Assignment 2 Solution and Discussion

[zareen]

Assignment No. 02
Semester: Fall 2019
CS605 - Software Engineering-II
Total Marks: 15

Due Date: 6/12/2019

Assignment no. 2 covers Lec#8 to Lec#17.

Objectives of Assignment:

• To learn the basic objective of software project planning.
• To understand the basic objective of requirements of a software project.

Uploading instructions:

• Your assignment must be in .doc format.(Any other formats like scan images, PDF, Zip, rar, bmp, docx etc will not be accepted).
• No assignment will be accepted through email.

Rules for Marking:

It should be clear that your assignment will not get any credit if:

• The assignment is submitted after due date.
• The submitted assignment does not open or file is corrupted.
• Your assignment is copied from internet, handouts or from any other student
(Strict disciplinary action will be taken in this case).

Scenario: 15 Marks

Suppose you are the Project Manager newly established Company that has initially hired 500 employees in its 4 departments (i.e. HR Department, Marketing Department, Sales Department, and Finance Department). The size of the company will grow later on. The owner of this organization is planning to implement a state-ot-the-art Employee Management System (EMS) Software in this Company.
Based on this scenario, answer the following questions:

1. Being a Project Manager, you have to take the decision for “Buy or Build”. Will you buy the Software from any renowned Software house or Developed your own EMS System? You have to Justify with solid reasons in any case. [5 marks]

2. You have to write 5 functional requirements each for any two of the departments (out of four) of your choice, that must be fulfilled during the software development. [5+5 marks]

Note:
Brief and relevant answer should be given (to the point). Long stories are not required.
Irrelevant and wrong statements will result in negative marking.
Copied assignments will get zero marks.

Submit “.doc” file only. Every student should provide his/her own work, exact copying of the assignment (or some portion of the assignment) from the internet or other students will lead to copy case and zero marks will be awarded. Do not put any query on MDB about this assignment, if you have any query then email us at [email protected]

Deadline:
Your assignment must be uploaded/submitted on or before 6th December 2019.

[zareen]

@zareen said in CS605 Assignment 2 Solution and Discussion:

You have to write 5 functional requirements each for any two of the departments (out of four) of your choice, that must be fulfilled during the software development. [5+5 marks]

There are four main activities in the requirements engineering process:

1. Feasibility study:
   An estimate is made of whether the identified user needs may besatisfied using current software and hardware technologies. The study considers whether the proposed system will be cost-effective from a business point of view and if it can be developed within existing budgetary constraints. A feasibility study should be relatively cheap and quick. The result should inform the decision of whether or not to go ahead with a more The requirements engineering process
   detailed analysis (feasibility report).
2. Requirements elicitation and analysis:
   This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and buyer, task analysis. This may involve the development of one or more system models and prototypes. These help the system developer understand the system to be specified.
3. Requirements specification:
   Requirements specification is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. Two types of requirements may be included in this document. User requirements are abstract statements of the system requirements for the customer and end-user of the system; System requirements are a more detailed description of the functionality to be provided.
4. Requirements validation:
   This activity checks the requirements for realism, consistency, and completeness. During this process, errors in the requirements document are inevitably discovered. It must then be modified to correct these problems.Of course, the activities in the requirements process are not simply carried out in a strict sequence. Requirements analysis continues during definition and specification and new requirements come to light throughout the process. Therefore, the activities of analysis, definition, and specification are interleaved. In agile methods,such as Extreme Programming, requirements are developed incrementally according to user priorities and the elicitation of requirements comes from users who are part of the development team.

[zareen]

@zareen said in CS605 Assignment 2 Solution and Discussion:

You have to write 5 functional requirements each for any two of the departments (out of four) of your choice, that must be fulfilled during the software development. [5+5 marks]

There are four main activities in the requirements engineering process:

1. Feasibility study:
   An estimate is made of whether the identified user needs may besatisfied using current software and hardware technologies. The study considers whether the proposed system will be cost-effective from a business point of view and if it can be developed within existing budgetary constraints. A feasibility study should be relatively cheap and quick. The result should inform the decision of whether or not to go ahead with a more The requirements engineering process
   detailed analysis (feasibility report).
2. Requirements elicitation and analysis:
   This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and buyer, task analysis. This may involve the development of one or more system models and prototypes. These help the system developer understand the system to be specified.
3. Requirements specification:
   Requirements specification is the activity of translating the information gathered during the analysis activity into a document that defines a set of requirements. Two types of requirements may be included in this document. User requirements are abstract statements of the system requirements for the customer and end-user of the system; System requirements are a more detailed description of the functionality to be provided.
4. Requirements validation:
   This activity checks the requirements for realism, consistency, and completeness. During this process, errors in the requirements document are inevitably discovered. It must then be modified to correct these problems.Of course, the activities in the requirements process are not simply carried out in a strict sequence. Requirements analysis continues during definition and specification and new requirements come to light throughout the process. Therefore, the activities of analysis, definition, and specification are interleaved. In agile methods,such as Extreme Programming, requirements are developed incrementally according to user priorities and the elicitation of requirements comes from users who are part of the development team.

[cyberian]

Buy it in:

1. Software license costs of the product
2. Renewal costs over period of contract
3. Support and maintenance contract costs
4. License costs of associated products, e.g. database license, digital certificate costs, etc.
5. Project management costs
6. Implementation costs
7. Escrow costs (if using)
8. Consultancy and advise (if using)
9. End user training

[cyberian]

You should expect to include the following costs in a build it yourself scenario:

1. Research of requirements
2. Project management costs
3. Cost of specialist design team and business analysis consultants
4. Costs of internal development team
5. Costs of outsourcing, if using
6. License costs for hardware and software development tools
7. License costs for associated software such as databases, digital certificates, etc.
8. Costs in time to market
9. Test support costs, including UX /accessibility testing, setting up and costs of test servers
10. Technical authors for user guides and other documentation
11. End user training
12. Environment costs
13. Code analysis costs (if performing)
14. Maintenance and new feature deployment (post production)

[cyberian]

@zareen
Type of Skills Needed To Build It Yourself
Team members need to come with a multitude of skills and experience.
The software development lifecycle requires knowledge across a number of areas:
• Project management
• Requirements analysis
• User journey development and related documentation such as state models
• Architecture design, including the review of certain protocols, database types, security measures, etc.
• Storyboarding and user interface design
• Management of usability / accessibility testing
• API development where needed
• Technical authors for user guides and other documentation
• Test case and automated script creation
• Testing of software across CIT/SIT/UAT and pre-production
• Environment design and setup
• Implementation
• Maintenance

[zareen]

Buy It In –Reinventing the Wheel is For Others
3.1 Software Vendors are Experts in their Field, Right?
3.2 Finding the Right Product at the Right Price
3.3 Do the Product Features Fit Your Remit?
3.4 Vendor Dependencies: Support and Hosting Options
3.5 Exit strategy – Managing Your Black Swan

[zareen]

@zareen
Build it and they will come…
1.1 Developing Your Requirements
2.2 Finding the Right Team
2.3 Supporting Your Application
2.4 Hidden Time / Costs
2.5. Outsourcing Obstacles
2.6 Exit Strategy – Managing Your Black Swan

[zareen]

@zareen said in CS605 Assignment 2 Solution and Discussion:

Being a Project Manager, you have to take the decision for “Buy or Build”. Will you buy the Software from any renowned Software house or Developed your own EMS System? You have to Justify with solid reasons in any case. [5 marks]

Part 1: Traditional reasons for buying
In my experience the case for buying software is often not made on the back of arguments that show why buying is a good idea. The usual route seems to be to analyse why building is a bad idea. This in itself says something. It is as if building is the natural answer and only problems with it make it necessary to take a different approach. So, what are these problems that have led people to preferring to buy a package?

Software development is risky
Software development is inefficient
Software development is not our core competency

[1] Mitchell Bingemann, “Dealers still fuming at ‘clumsy’ Telstra system”. The Australian, 2 June 2009.

[2] Tom DeMarco, “Software Engineering: An Idea Whose Time Has Come and Gone?” IEEE Software, July/August 2009.