Latest Activity In Study Groups

Join Your Study Groups

VU Past Papers, MCQs and More

We non-commercial site working hard since 2009 to facilitate learning Read More. We can't keep up without your support. Donate.

Your company has got a project for developing a software system. A similar software system was developed in your previous company. You discover that your company's interpretation of requirements is different from the interpretation taken by your previous company. Cost of project will tremendously increase if ambiguities in requirements are not resolved. You have also an ethical responsibility of confidentiality to your previous company. Discuss what you should do in such a situation?

Note that GDB will remain open for 2 days only (from 11th Feb to 12th Feb, 2013) and no extra time will be given for posting the answer. Therefore, make sure that you submit your answer within the given time. 

 
Also before posting your answer, keep the following important instructions in your mind.

Important Instructions:

  • Your answer should not exceed than 200 words.
  • Use the font style “Times New Roman” and font size “12”.
  • Your answer should be relevant to the topic i.e. clear and concise.
  • Do not copy your answer from Internet or any other source. Such answers will be marked Zero (0) and may damage your grade in the course.
  • You cannot participate in the discussion after the due date via email or MDB.

 For any further queries regarding GDB, email at cs504@vu.edu.pk.

Views: 5193

Replies to This Discussion

ap solutn da do q k 200 q k 200 ma just no to nhn aye ga na sweet siso solution

yahn to aj confusion hi confusion hai tariq bhi k idea hi dkhna pary ga. har koi confuse kar raha hai

In this situation I will actually not use the previous company's software. But we will discuss and review ideas & strategies if they are getting it right or not?  Then collect all information from our client . get new innovative ideas as the requirements & technology are changed with the passage of time. use my experience and knowledge, I will make more effective software system than the previous . 

Friendss ye meri GDB k main points thy aap b inko elbrate kr  dy or explain kr dy GDbwill b solved!!  i think ab kisi ko koi issue ya confusion ni honi chahye   

same ideas are mine................

hmmmmmmmmmmmmmmmm sohni khan kch paly par gya thanxxxxxxx

cs 504 gdb just idea 
To have a mature field in anything, we have to first define what that field is — which, we haven’t really done. As McConnell points out, there are two main points of view, software engineering^ and software engineering^^. As the field matures, these two viewpoints will come a bit closer (or perhaps one will be redefined).
In a mature field, the well-known best practices are disseminated among the various practitioners, and there is some sort of measurement to gauge whether those practices are being followed. As the SEI report on process maturity points out, the majority of companies have a way to go in adopting best practices.
In a mature field, the public has some level of protection between the practitioners and themselves (in particular where the public’s health is at risk) — usually in the form of certification or a professional license (e.g. doctors, lawyers, professional engineers). This doesn’t yet exist in the United States, except in Texas.
In a mature field, there is a well-established curriculum for obtaining the knowledge required to successfully work in industry. While there are about 21 universities in the United States that are accredited by ABET (the Accreditation Board for Engineering and Technology), and that is about 21 more than we had eight years ago, we still have a ways to go.
And, a mature field has an established code of ethics. The ACM wrote a code, but there are no “official” consequences if one violates it, and I’m not aware of any public tests written around it / requiring knowledge of it.

Solution:
Software projects are notoriously difficult to manage. Stories of projects delivered late, over-budget and/or defect-ridden abound. You have likely been involved in a few such projects yourself.
Many trainers and coaches claim to offer a solution to software delivery problems. However, before diving into the latest project management fad, it’s important to understand the underlying reasons why software is so difficult to manage.
The problems begin with requirements. There is a persistent myth that software requirements can be fully determined at the outset of a project. Despite repeated project failures traced to faulty requirements, we continue to believe that requirements must be fully documented before software development can begin.
The underlying rational is that we need to do a better job of defining requirements. If we can just get the requirements right, the rest of the project will be easy.
The next fallacy involves change. Changes are to be expected. You will need a rigorous change management system to define, track and control change requests. Unfortunately, most change management systems are really change prevention systems. They only cause more problems.
Where Does Change Come From?
Any project lasting for more than a few weeks is likely to encounter technology changes. Operating systems, security systems, APIs, development tools, etc. will change and require that the team make adjustments. The alternative is to not upgrade the underlying software and risk deploying to the end user with old, possibly unsupported, code.
Competitive changes are a constant threat. If a competitor announces or ships something unexpected, you will be left scrambling to catch up. The only thing you can do is revise the requirements.
Business process changes are always looming. As management strives to improve productivity, reduce costs, react to new regulations, and deal with organizational changes, the software will need to adapt.
Resisting such changes is futile. Even if you succeed in preventing changes to the project plan, you will end up delivering software that is outdated before it arrives.
Another big trouble spot for software development teams is estimation. Any estimate is only as good as the data available and the assumptions made. Faced with changing data and questionable assumptions, project managers will often do their best to hold to the initial estimate. Bad idea.
As changes occur, estimates become less accurate. Even seemingly small changes can have a dramatic impact on an estimate. Force fitting the new information into the original estimate will result in late delivery, defective code or both.

 bakwaas or ghair zarori cheexy post krna band kr dn ab!! studnts or confuse hojye gy!! 

I agree with sohni khan. jst confuse aur kam ki aik bt nai.

soni khan dnt do this he is our senior and we should give respect to them un ki koshish to sb students ko active krna ha but way is not right well thanx of u for giving correct ideaaaaaaaaaaaaaaaaaa

agree wid silent

RSS

Looking For Something? Search Below

Latest Activity

VIP Member Badge & Others

How to Get This Badge at Your Profile DP

------------------------------------

Management: Admins ::: Moderators

Other Awards Badges List Moderators Group

© 2021   Created by + M.Tariq Malik.   Powered by

Promote Us  |  Report an Issue  |  Privacy Policy  |  Terms of Service