SDLC Roles and Responsibilites

There are many roles and responsibilities that build up the foundation of any Software Development Life Cycle (SDLC). Within the institute where I work, we have project managers, business solutions analysts, developers, designers, testers and more. Each and every role plays an important part in order to attain success within a project.

Project Sponsor & Business Representative: to start a project you need an idea and money. This is where project sponsors and business representatives come to play. They are the backbone which hold everything together, for as the moment a sponsor decides to stop funding that is the end of the project. The sponsor may not be there during every part of the SDLC however they will have their business representatives checking in as well as constant reports from the project managers.

Working in a HE institute it varies on whether the project is internal or external. If internal it could be the case that a certain faculty will be the sponsor. If external it could be the government, UCAS, or many other organizations.

Project Manager: They are crucial within any SDLC as they are probably the only one who is involved from the feasibility study (planning) all the way to the implementation. A good project manager will make sure everything is organised and on schedule while at the same time keeping and raising morale when low.

Within my workplace we have a Project Managers Office, where a group of project managers can be found each leading different projects.

From a brief conversation with a project manager leading the mobility project that I’m currently assisting with, I realised that they do so much in order to keep things afloat. They have to run a tight ship, making sure deadlines are met and the project itself is on schedule or as close to.

The most challenging part for them personally is making sure that all the needs are met, as in making sure that every bit of information is gathered initially with great detail so there won’t be conflicts later on in development. They also understand that although everyone is to work as a team the harsh truth is that if the project is to go downhill the blame goes to them even if the problem isn’t within their grasps.

Business Solutions Analyst: A business analyst is an important role in the SDLC, they are involved from the planning all the way until the actual implementation itself. Their role itself is mainly focused as being the middleman between the consumer and the developers. They are responsible for providing detailed information regarding the requirements for the projects and what exactly the outcome should be.

At The University of Westminster, we have an amazing team of SITs Business analyst. They have been very helpful and friendly to me, whenever I have a question regarding the many faculties within the institute or even HE itself they are my go to team.

After my 1-1 meeting with a member of the SITs business analyst team, I’ve gained a good understanding on what they do and how they get it done. Their role requires them to retrieve information on the required needs for the project. This information is then processed, compiled and sent to the development and design team in order for them to have a clear picture of what is to be developed.

However, it doesn’t stop there, they then have to continuously update requirements as they come through as well as provide feedback to the project manager. When it comes to the testing stage they have to plan and schedule meetings with the consumers and testers to see if there are any major problems that they can resolve themselves, if not feedback is given back to the developers to debug.

Outside of the project environment, The SITs business analyst have access and knowledge on how to resolves issues within SITS. Whenever a FIXIT token comes through regarding anything to do with SITS it always gets through them first. Most of the time it’s basic problems e.g. writing SRLS, which they can resolve. However, when they do receive those few pesky problems which are a lot more difficult and fragile they send them over to my team, solutions.

Developers and Designers: The core of any SDLC are the Developers and Designers. Their main role is to plan and create the solution. They work very closely with the business analysts and project managers, in order for them to have a detailed idea of what exactly they are to do. They do not just come in the stage of development they are required from the beginning during the early feasibility studies and requirements engineering. Here they provide information on whether the project is even possible, then provide a general idea of how much plus how long it would take.

I work within a team of software developers, as an apprentice. Since I’ve started, I’ve been brought along to many meetings. Many which have given me a great insight into how things are processed, discussed and finalised. I really got to see first-hand the importance of communication with the rest of the team, both in (within the developers) and out (Project managers, business analyst etc…).

Within the team and depending on the size of the project. I can see that there are members that are working on small side projects while at the same time working as a whole team to tackle the major global projects.

Other than development itself, we are also 3rd line solutions. When a problem is logged it would go through an order of 1st line, 2nd line and the 3rd line.  Most cases are resolved before they get to us, here at 3rd line. However, there are certain cases that arise which can be problematic, requiring a more technical approach.

Testers: In order for successful implementation, testing is crucial. The difference between a bad ‘product’ and a great ‘product’ varies on how well said ‘product’ has been tested. Testing allows faults to be pin pointed, minor tweaks as well as adjustments to be made and all in all a much smoother ‘product’. From my research into SDLC roles and responsibilities, I’ve read on blogs and forums how there are many cases where testing was cut out to maximise profit. This to me is bad practise, no one will ever create the perfect software in their first try, it is only through constant testing that you can create something that goes above and beyond.

Within my work place, during the SITs upgrade I assisted our SITs Business Analyst team to visit many different faculty members. We were required to record the entity screens that they use on a daily basis. We then spoke to them on things that can be changed and added that would benefit their process. Finally, they are to be booked into testing in a supervised environment where if any problems where to arise they can be tackled asap.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s