tag:blogger.com,1999:blog-6852195426257819062.post4579647884175981551..comments2023-05-25T21:12:54.319+05:30Comments on The Soft New World: Change and Complexity: The Software Engineering ResponseSubhajit Dattahttp://www.blogger.com/profile/12152416536862663611noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-6852195426257819062.post-32911750156395883022011-02-04T02:35:31.928+05:302011-02-04T02:35:31.928+05:30Sreenidhi T (MT2010146):
Change is inevitable, pr...Sreenidhi T (MT2010146):<br /><br />Change is inevitable, probably the only entity that does not undergo change. Having stated that, it is only acceptable as a customer or an end user to view upon the software being developed as a customizable product, meeting his or her changing requirements.<br /><br />Hence managing this continuous process of change in the development of any system, more so in the field of software engineering, is essential as an inherent quality in the developer as well as the development lifecycle.Sreenidhinoreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-55881510513731542962011-02-02T10:19:04.731+05:302011-02-02T10:19:04.731+05:30The purpose of breaking down the problem at hand i...The purpose of breaking down the problem at hand is to simplify the process so that it is easier to tackle the smaller components than single large one. When the problem is broken down into too many smaller components it becomes difficult to manage and co-ordinate the sub-problems. So it is better to first have bird's eye view of the entire project and the divide the problem with a proper trade-off which gives both simplicity and manageability.Skanda Kumar (MT2010143)noreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-83769769049171507702011-02-02T08:47:55.195+05:302011-02-02T08:47:55.195+05:30According to me in the each and every product deve...According to me in the each and every product development they are strictly following the SDLC model based methods since it is basically the they will apply the SDLC methods based on the user specification and this architecture or models are not static since each can design of his own model for his own product development. Since customer requirement is going to change day by day and demand for more sophisticated and extensible softwares are in demand in the market so a software engineer should think of development and design perspective that "if we design and develop a system how many years it can stay in the current changing market" in this perspective all the complexity and change related aspects to be considered.Gajendra (MT2010040)http://gajendra.ganiga@iiitb.orgnoreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-86097156460158312612011-02-02T08:39:10.669+05:302011-02-02T08:39:10.669+05:30Asha Kiran B(MT2010017)
The idea of having a pr...Asha Kiran B(MT2010017)<br /> The idea of having a prototype done is not practical all the time. Also, the user's ability to comprehend prototypes could impact the very process of building a prototype. Also,is'nt a prototype something meant to be thrown away? It is a strict norm that no re-use has to happen using a prototype. <br /> The root cause of all of this is the ambiguity in the way requirements are specified. Isn't it possible at all to come with a 'non-ambigiuos' se of requirements? May be, the world should have software engineers of specific domains? Isn't it wiser to have software engineers as part of the companies themselves; that come over to software giants to get software made? Or, are the possibilities so limited that it is impossible and unprofitable to have domain-specific software engineers? Or,are we ( software engineers )so annoyingly costly to have within non-software companies?!Ashakiranhttps://www.blogger.com/profile/03950487637887981160noreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-64880665188549912052011-02-02T08:35:03.453+05:302011-02-02T08:35:03.453+05:30Life is unpredictable. The so called 'normal c...Life is unpredictable. The so called 'normal course' is almost undefined when life is concerned.<br />Life is complex. It is not just ourselves that we have to look into, but as social beings, a lot depends on the impact each of our decisions has on others concerned with it. <br /><br />The same is the case of Software Engineering. We can never be sure of what is next in store for us in the course of development of a product. It is complex as we have to cater to multiple stakeholders interests. <br /><br />The 'normal course' of a linear development plan never can become a reality. We have to constantly address the changing requirements at all stages and phases.Since, as in life we learn from our mistakes and our failures are the stepping stones to future success, this has to be inculcated into software engineering process as well in the form of feedback.<br /><br />In my opinion, feedback has to be present, but present right from the inception stage. The feedback to a prototype may need something to be developed from scratch. So we should not just keep postponing feedbacks to later stages of development. This can realize a lot of cost cutting and better user satisfaction.The right design is the key to avoid a lot of reworking and for this our base, which we build from study of the background, technology and analysis of user requirements, has to be made strong by frequent iterations.Parvathy S.Pillainoreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-33299440392990198372011-02-02T01:44:24.612+05:302011-02-02T01:44:24.612+05:30I hope the changes that the user need can be dealt...I hope the changes that the user need can be dealt till some point in time. There can be some expectation of a user which urge the software to be changed dramatically. In such cases the complexity for the development of the system/software will be increased. So <i>can there be a limit for the expectation of change by the user at certain point in development phase</i> we must think of.Vinaya M Shttp://MT2010166noreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-84123210448565370902011-02-01T22:49:01.412+05:302011-02-01T22:49:01.412+05:30As you have mentioned, change is one of the centra...As you have mentioned, change is one of the central challenges in SE. This 'change' comes from the fact that<br /><br />1. No person is clear about a product's requirements before building it. It is a never ending loop of change.<br /><br />2. Perception of these requirements. There is no clear formula / rule which translates a requirement from colloquial language to a mathematical form (which would leave no room for different interpretations). Since, a person has to rely on natural language to make sense of these requirements, change is inevitable. <br /><br />3. Technology is changing everyday. Today technology 'a' is in vogue, tomorrow no person will even remember it. Hence, there is a constant need to update our knowledge and fit into the picture with appropriate technology. <br /><br />As you have mentioned, 'change and complexity boils down to being able to monitor, control, and leverage the myriad feedback paths', this does make software engineering processes easy to understand. This is way to converge to a space where everything is modeled as a rule and sticking to it will make everyone's life easy. <br /><br />Feedback also is a cause for constant change in the requirements. If there was no scope for feedback, there would be no changes. But no changes in the requirements would be in a parallel world where everything is understood in the first requirement analysis meeting.Pratibhahttps://www.blogger.com/profile/06909793141697072316noreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-32826756846827185622011-02-01T20:59:09.161+05:302011-02-01T20:59:09.161+05:30Bhargav Naik (MT2010083)
The change in user requi...Bhargav Naik (MT2010083)<br /><br />The change in user requirements can be dealt with by creating prototype versions and taking feedback from the customers, which may reduce a lot of rework in the process.Anonymoushttps://www.blogger.com/profile/14377618070834788419noreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-51237785456426589932011-02-01T20:49:37.568+05:302011-02-01T20:49:37.568+05:30Bhargav Naik(MT2010083)
The change in the user re...Bhargav Naik(MT2010083)<br /><br />The change in the user requirements can dealt with by creating prototype versions and taking feedback from the customers, which may reduce considerable rework.Anonymoushttps://www.blogger.com/profile/14377618070834788419noreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-78383499823255174282011-02-01T15:29:28.019+05:302011-02-01T15:29:28.019+05:30Krishna Kant Harkut(MT2010064):
I feel that SDLC(S...Krishna Kant Harkut(MT2010064):<br />I feel that SDLC(SOftware Development Life Cycle) must be strictly followed for all types of project development(small scale or large scale projects) as what ever we develop it is for the users and we would like to give the user the product they visualize.This is achieved by SDLC which tailors yours development according to the user's need. <br /> Also the SDLC for any project development never ends because user's needs are not constant.Based on the user's new requirements the SDLC phases are again carried out.So it is the software engineer's duty to carry out the SDLC phases from time to time.KRISHNA KANT HARKUT(MT2010064)noreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-66602579264106255872011-02-01T04:44:12.116+05:302011-02-01T04:44:12.116+05:30The SDLC plays an important role while developing ...The SDLC plays an important role while developing a product.There exists simple models like water fall model and complex models like iterative ,prototyping and RAD models.But one cannot decide a unified model for all the softwares.<br /><br />Choosing the model depends on what kind of software we are building.For a simple ,low budget project it is not recommended to go for complex models ,as they consume more time ,labor and cost.<br /><br />On the other hand ,building some softwares in one go is not possible.The requirements are specified once some part of output seen.In such cases a slightly complex model called iterative model can be used.<br /><br />Similarly there exists a bunch of models each of which can be used for solving a kind of issue/issues and selection of the model becomes a precursor for developing any software.ravi_endlahttps://www.blogger.com/profile/03781576740569427061noreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-73887947139757549812011-01-30T22:51:25.808+05:302011-01-30T22:51:25.808+05:30This comment has been removed by the author.Shreya Barsaiyanhttps://www.blogger.com/profile/06848734310936759524noreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-83389717429051818922011-01-30T12:19:04.074+05:302011-01-30T12:19:04.074+05:30Nilesh Inamdar
(MT2010050)
Software engineering pl...Nilesh Inamdar<br />(MT2010050)<br />Software engineering plays a critical role in dealing with change and complexity. Over the years it has been seen that user requirement keep on changing and will continue to change. The product must be made extensible. We must be able to modify the existing software with minimum amount of change without hampering(or changing) other parts. To achieve this, each and every design steps must be planned and noted in a standard manner. Standard SDLC must be followed. Regular feedback is must to avoid lot of unnecessary work. Expert opinion is very crucial in the field of software engineering as they have worked upon many projects and know better which things must be handled carefully.Unknownhttps://www.blogger.com/profile/13782280249734551768noreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-71964722272202812772011-01-29T19:15:24.261+05:302011-01-29T19:15:24.261+05:30The user views and requirement can change over tim...The user views and requirement can change over time. Feedback is indeed helpful towards conveying the developer about the added needs.To include these changes in system, development model need to be adaptable. Spiral model or Iterative and incremental model are acceptable in this scenario. Once the requirements are available in detail the first prototype of the system can be made available to the user. Based on feedback further revisions can be made. Analysis, design, implementation and testing can be iteratively done until a stable and acceptable version is devised.<br /><br />MT2010101Philip Josephnoreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-36158595901880876182011-01-27T23:09:23.637+05:302011-01-27T23:09:23.637+05:30I feel that the changes and resulting complexity a...I feel that the changes and resulting complexity are inherent part of any software which gives the user 'exciting' experience (Here 'exciting' refers to classification of requirements refer: The QFD handbook By Jack B. ReVelle, John W. Moran, Charles Aaron Cox page no. 174)<br />Hence it is the software engineer's responsibility to incorporate the changes which can occur in the middle of SDLC. The classical waterfall model fails in this aspect as it can have blocking stages.<br /><br />According to me, 'the scalable design' is the key to counter the scale-up with growing requirements & change requests in the software.<br />The design should be 'model oriented' which identifies the stable parts. Also the classical principle of 'High cohesion, low coupling' should be taken into account for designing the modules.<br /><br />Incremental SDLC model will also help in this scenario which can incorporate 'scalable design' & make the system more flexible.Ashish Tergaonkar (MT2010159)noreply@blogger.comtag:blogger.com,1999:blog-6852195426257819062.post-72120320074165073442011-01-25T09:33:32.215+05:302011-01-25T09:33:32.215+05:30Deepthi Ravisankar(MT2010031):
Design is difficult...Deepthi Ravisankar(MT2010031):<br />Design is difficult to predict and is expensive as it requires people with innovative skills whereas construction is easier to predict.<br />The non-linearity in real life is partly because software development is a design activity, and therefore hard to plan and cost. Also its basic ingredients are rapidly changing.And then the whole process depends on individuals involved, and individuals are hard to predict and quantify.<br /><br /> <br />The key to feedback mechanism is to frequently produce working versions of the final system that have a subset of all required functionality. These working systems have limited shortcomings. They should be fully integrated and as carefully tested as a final deliverable system.Deepthi Ravisankarnoreply@blogger.com