Here's a less-helpful answer: the industry itself hasn't really figured out SDLC yet.
There's a lot of differing opinion on what methods to use when developing software. If you haven't already, try googling or Wikipedia-ing some of the more common buzzwords in use today: Waterfall, Agile, Test-Driven, Scrum, RAD. There's volumes of stuff written about these ideas and their relative strengths.
The thing to understand is that the software development industry doesn't have a very good idea about what the life cycle of development should be. There's been lots of study about what it it is, but usually that study is accompanied by commentary that talks about how badly it's failed. As such, there's been several schisms in the SDLC space over the past 15 years or so, as people and companies invent & implement new ways of building software.
Likewise, schools don't handle this sort of situation very well. They want to be able to teach a particular idea with enough depth to fill a semester-long course. SDLC doesn't fit with that very well, as there's many (often conflicting) schools of thought. These may be too new to be really understood well (you have to really understand something to be able to teach it), or they might be too deep to really get into in a classroom setting. The best most college classes can do is to pick up older SDLC ideas and materials (some of which may already be out of date in the industry) and teach that as one example of how its done.
Individual companies will each have their own take on SDLC (in fact some will have multiple takes depending on the department). In fact, one of the things you'll want to ask about when settling into your career is how they go about doing their development. For instance, I appreciate working in an agile, high-flexibility (some would say chaotic) development environment with highly-skilled coworkers. That's not necessarily good for everyone; developers with less skill and/or confidence might prefer a more structured, top-down approach.
My best advice would be to not expect to have an "answer" to the question of SDLC. Instead, be prepared to read/listen to the experiences of others and try to come to your own conclusions about how to build software. Stay flexible, read a lot (especially websites where the information is newer), and possibly attend conferences if you can. Once you get comfortable doing development you'll be able to understand the issues better and perhaps contribute to a better solution.