Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have been trying to learn the basics of software engineering principles, but I have come across a question that I cant find enough detail on to answer, any help would be appreciated:
For each of the process models (i.e. waterfall, incremental, prototyping
and spiral), how does the model handle a significant change in requirements late in the
development?
Thanks in advance.
I think this question can be simplified - broadly speaking there are two types of software development life cycle:
Iterative (or agile) methodologies like Scrum and Extreme Programming.
Sequential (or "big design upfront") methodologies like waterfall.
The iterative methodologies rely on the experiential feedback from within the project. In Scrum, the sprint review provides guidance concerning what can be achieved in the next sprint and the review of the product backlog can promote the latest requirements to the top of the priority list. In iterative methodology, the evaluation phase of the increment can feed into the planning for the next iteration.
These two examples show a clear point at which the methodologies can adapt and react to new requirements.
There are of course some specific details beyond this broad stroke explanation. For example, a Scrum team wouldn't actually change scope until the end of the sprint - unless the sprint was completely abandoned. As a result there could be a small delay before new requirements could begin implementation.
With the more traditional methodologies such as Waterfall, accommodating adaptation is more difficult because you are constrained by the current phase of the series of phases. To adapt requirements it's likely going to involve non-optimal design and implementation because of the nature of the change being bolted on. If the changes in the requirements were significant enough the entire development may be abandoned and restarted. At least with the agile methodologies you will have already developed, or in fact shipped, some increment of business value.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Knowing all the advantages TDD offers. It is possible to apply strictly and all the time in all kind of projects (large projects)? Or is it nothing more than an exaggeration?
One has to consider both advantages and disadvantages, the main disadvantage being the time cost. You typically need to write 1 line of unit testing for every line of code. TDD makes no sense if your functionality is very likely to change a lot in the future, because you will have to rewrite all tests all the time. For example a case of an early prototype, where you mostly want to just test some idea rather than making a super stable application.
Another case is if you want to support the change in your application. Then TDD will give you benefits in the long term. Is it possible to apply strictly? Certainly it is possible, but not easy, as it is typical that business people try to reduce short-term costs and disallow using TDD fully. TDD creates short-term costs (writing the tests) in hope to reduce long-term costs (loosing quality due to sudden bugs or extensive manual tests).
Sometimes it is not possible to use TDD.
For example, when writing classes in c++ to display GUI components, it makes no sense to unit test everything. If using MVP design pattern, models in MVP trio should be unit tested, but not the views.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
For the past 3 semesters at school I've been taking software engineering classes where we've been learning about the various life-cycle models. The textbook for the course is a collection of IEEE articles from the 1970s and 1980s. The professors has a generally negative attitude towards just about every model. He says they are all useless. The main models we talk about are waterfall, evolutionary, incremental, spiral, and my favorite (sarcasm), the automated software synthesis model.
My questions:
What are some other models used today (even if only in theory, as in the case of automatic software synthesis)?
and
What is the most prevalent model used for large projects in the industry (Google, Microsoft, Apple, etc.)?
I hear a lot of people talk about using Agile, but more often than not I get the impression that they're not really talking about an actual life-cycle model. I think most of the time people just mean that they don't design or document like they should...
See this questions on programmers (which was closed, but still an excellent reference starting point): Are there any major alternatives to waterfall and Agile?
Nearly all of these lifecycle models have been used successfully in industry on large projects, some more easily than others. Choice of lifecycle model depends on many factors including size, cost, safety concerns, time, volatility, "researchiness" of the project, risk, stakeholders, schedule needs, etc and may vary from project to project, even within the same company.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Scrum is one methodology in agile software development right? What are the main activities in Scrum?
I hope this will help.
Nains...
Scrum is indeed an agile software development methodology.
It's more then a set of activities - there are a set of core assumptions and ideas that underlie the activities. Nains' answer contains a cheat sheet explaining very briefly the important concepts.
To answer your question in the most basic sense.
Gather user stories
Determine priority within these stories, chop them up in small, manageable tasks.
Code-code-code
Every day: short meeting where team members explain their progress, what they're working on, and where they get stuck on.
Every two weeks (or week, or month... depends on your project): deliver a working copy of what you have.
Return to step 1.
One such loop is called a Sprint. The essential step is that you begin by revisiting your assumptions what the software needs to do - the user stories, and their priorities.
Also note that this is a short cycle, within a very short period of time, the users get feedback.
Note that there is a lot more to be said about Scrum - if you want more details, I recommend a good book, or at the very least reading the Wikipedia article.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
How do you start planning a fairly large project? Do you immediately start writing up the major classes and break it down further and further? Do you sit down and draw out some UML?
I'm designing my first large project (well, large compared to the other ones) and I'm looking for ideas.
I suggest reading about agile methodology and scrum.
Large Projects would be beneficial when used Agile scrum methodology.
Agile methods divides your projects into smaller sprints giving one the time to prioritize the main features to be concentrated & completed.
Continuous interaction with client means less ambiguity, more real value. The client would see live ideas before final. So more improvising at very early stage with ample of time to make it better.
Bug fixing process gets speedy. Less the bugs, more efficient the Project!
By using time-boxed, fixed schedule Sprints of 1-4 weeks, new features are delivered quickly and frequently, with a high level of predictability. This also provides the opportunity to release or beta test the software earlier than planned if there is sufficient business value.
Improves Quality. By breaking down the project into manageable units, the project team can focus on high-quality development, testing, and collaboration. Also, by producing frequent builds and conducting testing and reviews during each iteration, quality is improved by finding and fixing defects quickly and identifying expectation mismatches early.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Someone within my organization has started pushing for us to pilot the CMU SEI's TSP process (see website here). I have an instinctual aversion to any attempts to cure software development illnesses with alphabet soup, but I would like to know if anyone has experience with this process and can provide tangible facts.
I used to be a fan of SEI's CMM. I even read Watts Humphrey's "Managing the Software Process" book cover to cover. I haven't used TSP but I suspect it has similar strenghts and weaknesses as the other software processes.
Definitely read about it and what they claim it can do and how to implement it, but be vigilant about keeping your software process small and flexible. You need one, but be careful about taking processes from someone else.
good luck.
We've been using this process for a few months now and I'm not particularly impressed. This process is only suitable for a strict command and control style of management where programmers are essentially bean counters. Most of the good parts of this process (size estimates rather than time estimates, self reviews, detailed plans, logging time against plans, and keeping a log of defects and errors for later review) can be implemented without throwing a bunch of money at SEI.