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.
Related
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
I need some idea regarding the development time estimation of a to be developed software. Though there are formal methods in theory like COCOMO , Function point ,etc, such methods seem impractical to apply before having any work done. (I am not sure if possible?)
I have attached a sample module. Please help me in learning estimation in the practical purpose.
Scenario: Student Registration Module
Check whether the student is new or already registered.
1.1. if already registered then activate the registration
1.2. If new student then, Record all the necessary data related with the new student. (certificates in different formats like pdf,docx, jpg,png)
Check for late registration. If late then apply late registration fee.
Time check: student registration must be done within a week of academic session start.
Also, I think the development time may differ in terms of programming language used. For eg. Java , C sharp or PHP. Please guide me with your understanding.
Thanking You.
I would warmly suggest you to read the book "Software Estimation: Demystifying the Black Art" by Steve McConnell.
You'll get many useful thumb-rules from there. Many derived from COCOMO :-)
E.g. the fact, that as you state the time will be different depending on programming language. It's true. some studies have found out, that the number of LOCs produced by a programmer doesn't depend on language. But the productivity of those lines does.
So some very basic rules in software-estimation:
Understand the cone of insecurity
Give estimate in ranges, not
in single numbers
Re-estimate continuously
Divide the task in
as many as possible smaller task, and estimate them individually.
Estimate in this order: size, effort, costs/schedule
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.
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
In a big corp, they often ask developers to fill in a matrix of what skills they have at what level. It's generally seen as a bit of a pain but is it actually useful, or another way for bureaucrats to try and reduce developers to a bunch of numbers on a spreadsheet?
Skills matrix are only partially helpful, they are good at giving you a general picture of your current "experience".
However these skills matrix does not include the most important aspect, the ability to learn.
This is the most important skill in IT in my view. And everyone learns at different speeds.
Eg. Throwing guy A into a new technology stack, and how long before he/she is productive?
Since IT/software development is a very wide field I regard skill sheets as quite useful. I used to be a Linux expert and my skill sheet reflected that. Then I shifted into iOS/Mac development and my now-employer asked me to fill out a skill sheet tuned to Mac... and I immediately noticed that I was novice in this field back then ;-) Vice versa, they were able to see whether I can fit into the company and where (in which team).
So of course they can be harmful if you lack the skills, but I think they make choices for employers easier (and I regard a big skill sheet in my CV as the most important part of the CV, even more so than the list of projects done).
The usefulness is totally dependent on what is being assessed. I work in an insurance company and this was done for all staff here. There was no category that I fit into and all the criteria were irrelevant.
I can see the benefit of assessing relevant criteria, it can identify weaknesses and target training, but those criteria need to be defined by someone who knows what you might not know.
Most of all, don't berate the bureaucrat for simplifying a complex object into a manageable set of information. As a programmer that's what you should be doing every day.
I think it is appropiate on big corps, but for small and specialized consultancies I would make a personal interview.
In big corporations if you dont fit in one place you may fit in other... in small teams I rather do personal assessment .
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.