Good Monday!
I have just passed by a question to describe about SDLC, it's been a while about this experience so I want to note out my understanding and experience on this concept. This will be an out of track post, back to where I used to be, a management knowledge.
So the generic concept of a manager is, you have to experience a lot. Some find its useful to read through book and other's experience to stock up your knowledge but I have a different idea, I want to experience the situation by myself in order to understand the feeling and what I have to react in the case with my trait, I don't think I might have the same feeling with you even we taste the same dish. That's the reason the pre-requisite of PMP exam is your 2 years of leadership experience, hold on ... it's a requirement process, it's a standard but not exactly what you have to have (I will write out another post about process and implementation later, it's something relate to my current job as DevOps). Out of track already, let's get back to the main topic!
So, let's start from a business idea, then this is a Initial Phase (please not confuse between SDLC and PM process, PM process might have more stuffs to start with the project charter and so on)
In this phase, you will do:
- Understand and consult to build up a business solution and application. This step will relate a lot on consultative sale skill, please note that you will have two types of sales to approach your potential. Product (active) approach, where you already had your product that meets (or partial meet) the need from your potential then you have to be very active talk/present about your superior of your product and what features that bring value to your potential's idea or drive their idea to your product line. Service (passive) approach, where you provide service, skill to implement your potential's idea into product then you have to break the ice in other way, so you have to listen and understand their story that why they come up with that idea, this is where you will start your conversation to show that you understand their current condition and how you might help to drag them out of the pond. This approach is more complex because you don't have any standard, product or any tangible concept to persuade them but you have to bring up some similar practice that can persuade your potential. Again, this session will involve into sales, pre-sales skillset and I don't think this is a place for that now.
- Capture/gather/implement requirement. This is where the Business Analyst works, the person with rich experience of the working domain on market (for our case, we discuss about software/IT) so this BA has to have rich user experience on the IT market with that business domain. For example, when you want to build up the requirement for an eCommerce system, this guy has to understand about the common term on commercial process and the popular eCommerce applications out there in the market. This person will implement the business ideas, needs into software requirements, which are common used for the business people in field but also have to stand out of the existing products to make sure the decision of making a new software is not building something out there again or we have to make a gained value (ROI) upon this software.
- High level architecture. This step is also relate to the requirement and early solution because it depends on the need and future vision on this business idea, we will plan up the road-map for this software growing. What is the target of this software, how we scale it up later, what is the integration should be, how we would like to target to the user base ... This step will involve with the Solution Architect person who has rich knowledge of the technology out there and their trend, so this SA person can decide and consult which solution should be application with appropriate technology (functional and non-functional requirements will affect into the outcome).
- Estimation and planning. Voila, here come a PM, obviously, it's depend on how you define a project, some might define a project since the sales starts (you have to spend effort/budget for the sales process to manager your client/potential until you can fish them up) or some just start a project when you have the SOW awarded, where all those stuffs above are done in the contractual phase to win the deal, sometime this step is a part of the bidding process but in very high level picture. So, what you are doing for this step! Basic concept for a PM, right, create a WBS list base on the high level solution and timeline requirement will help to line up the milestones schedule and draft costing (human resource, other resources, integration cost and all the other costs that might rise during the Risk identify process will add up into the cost and schedule). I'm talking a lot about PM, BA, SA roles, seems we're doing with traditional RUP, waterfall process, how about Agile, no more PM, right! Yes, no more traditional manager but who will take care for the budget and schedule of release, PO, he is the one who will own those stuffs so you can say PO or PM, who is the one responsible for the budget and schedule of the outcome software will be the main stakeholder of this step.
- Project form up. This can be a not involved step but you have to prepare and facilitate all the project infrastructure and facility such as project team, members, hardware resources, working environment, process, training plan, procurement third party resource ... It's an easy missing step because when you do the cooking, usually you just remember about the material for your dish but don't forget your frying pan, saucepan, ladle, chopping boar, stove etc ... you don't have an existing kitchen everywhere :D
Alright, it should be somewhere enough for the Initial phase. Move to the cooking, oh, yes, Implementation Phase.
- Detail design. So we already had the detail requirement, the high level architect then now is the step to break down the project work into doable/implementable pieces. We will need a Technical Architect here, this one is a detail technical person that has deep knowledge on the specific technology that we defined the software to be built up from the high level architect. The TA will break down the solution into systems, interfaces, modules, components, transactions ... then team members will start to perform the design of each unit component for the implementation/coding. Again, come back to the Agile terminology, now you can see a lot of full-stack developer, this is another trend to build up a mature Agile team from requirement capturing/understanding (you don't have to form up a very formal requirement set at early stage) to design, implement then testing (doing the task of automation engineer in test).
- Implementation. This is a biggest part of the project, although it's just a simple work, IMPLEMENTATION but how the project is implemented is the whole concept how the PM manages the project (obviously there are other workflow competencies). This step the team will base on the requirement, design then implement the features and unit test. The most important is the integration planning when integrate the modules, components. I don't mentioned a lot on other aspects of the project will impact into the project such as Change Control Management, Risk Management, Procurement Management ... because this article is focus on SDLC but not on Project Management process.
- Testing. Some might take this step into a phase because testing is also a big area that we have to explore, there are multiple types of testing from the level of testing from component/function, to integration, system testing to regression testing, then non-functional testing, load/stress testing, harden testing, performance testing or some can define as white/black box testing. Then we have different ways to perform testing such as manual testing, automation testing. The testing process also applies some phases too, based on the requirement and solution, we will define the test bed, test suite then test cases. From those artifacts, the most cases, the integration/regression will be implemented for automation to reduce the testing effort. Please also note an important of testing step so there is an implementation process that focus into quality result called Test Driven Implementation.
- Packaging. This step can be in implementation or in the next phase, I put it here as we might have big effort to implement the build script for the automation build and packaging process (as part of CI/CD process)
So the next phase is Transition Phase.
- Deployment. This step is to deploy the package into Production environment. We can say from this step, the output of the Implementation phase is a shippable delivery (Agile term for an outcome of each Sprint). Involve into this step we have to take into account about some concepts that will be used for after production support such as cut-over planning, cut-over time, disaster recovery plan, production data migration ... Those items are used when:
So after is phase, usually the software project is completed, which the project scope usually was defined for the software development. Rarely, some SOWs might have the addendum with X years of software maintenance included but almost the cases the maintenance project will be separately. The next phase as you can guest, it's Maintenance Phase.
- Support and fix defect. This step is parallel with the step below, this is the action to support end user how to use the new system correctly, perform the fixing defect on production usage. For this Maintenance phase, we have to have a ticket system in order to define and track the flow of an incident from multiple levels of support, we should get the knowledge of ITIL service to perform the service support and service delivery for this phase. There are some terms and concepts involve into this phase such as:
It's quite a bit on a SLDC detail, again, this is not totally the correct definition or explanation but this is my knowledge and understanding, you can refer to this article for your information. You can find a standard definition here which has the same content with different steps.
I will have another post to talk about some items about software process, Development vs Maintenance support ...
Later!
I have just passed by a question to describe about SDLC, it's been a while about this experience so I want to note out my understanding and experience on this concept. This will be an out of track post, back to where I used to be, a management knowledge.
Use Case:
Tell me about your understanding on SDLC from a business idea till a software retired.Solution:
I'd better call this as a generic answer. Please note, there is no right or wrong in management, there is no clear black and white in a world of management (even in your life), it's just left and right, when you are on this way, the tree might be on your right but when you are at the other side, that same tree is not on your right anymore but turns to your left side already. So, when you take a PMP examination, there is no right or wrong answers, just what is the closest option in the provided situation. Even, you are a certified PM, you're not sure a good PM because management is an event driven solution, this is why PM/manager is another track that not really involve into bitwise operation :).So the generic concept of a manager is, you have to experience a lot. Some find its useful to read through book and other's experience to stock up your knowledge but I have a different idea, I want to experience the situation by myself in order to understand the feeling and what I have to react in the case with my trait, I don't think I might have the same feeling with you even we taste the same dish. That's the reason the pre-requisite of PMP exam is your 2 years of leadership experience, hold on ... it's a requirement process, it's a standard but not exactly what you have to have (I will write out another post about process and implementation later, it's something relate to my current job as DevOps). Out of track already, let's get back to the main topic!
So, let's start from a business idea, then this is a Initial Phase (please not confuse between SDLC and PM process, PM process might have more stuffs to start with the project charter and so on)
In this phase, you will do:
- Understand and consult to build up a business solution and application. This step will relate a lot on consultative sale skill, please note that you will have two types of sales to approach your potential. Product (active) approach, where you already had your product that meets (or partial meet) the need from your potential then you have to be very active talk/present about your superior of your product and what features that bring value to your potential's idea or drive their idea to your product line. Service (passive) approach, where you provide service, skill to implement your potential's idea into product then you have to break the ice in other way, so you have to listen and understand their story that why they come up with that idea, this is where you will start your conversation to show that you understand their current condition and how you might help to drag them out of the pond. This approach is more complex because you don't have any standard, product or any tangible concept to persuade them but you have to bring up some similar practice that can persuade your potential. Again, this session will involve into sales, pre-sales skillset and I don't think this is a place for that now.
- Capture/gather/implement requirement. This is where the Business Analyst works, the person with rich experience of the working domain on market (for our case, we discuss about software/IT) so this BA has to have rich user experience on the IT market with that business domain. For example, when you want to build up the requirement for an eCommerce system, this guy has to understand about the common term on commercial process and the popular eCommerce applications out there in the market. This person will implement the business ideas, needs into software requirements, which are common used for the business people in field but also have to stand out of the existing products to make sure the decision of making a new software is not building something out there again or we have to make a gained value (ROI) upon this software.
- High level architecture. This step is also relate to the requirement and early solution because it depends on the need and future vision on this business idea, we will plan up the road-map for this software growing. What is the target of this software, how we scale it up later, what is the integration should be, how we would like to target to the user base ... This step will involve with the Solution Architect person who has rich knowledge of the technology out there and their trend, so this SA person can decide and consult which solution should be application with appropriate technology (functional and non-functional requirements will affect into the outcome).
- Estimation and planning. Voila, here come a PM, obviously, it's depend on how you define a project, some might define a project since the sales starts (you have to spend effort/budget for the sales process to manager your client/potential until you can fish them up) or some just start a project when you have the SOW awarded, where all those stuffs above are done in the contractual phase to win the deal, sometime this step is a part of the bidding process but in very high level picture. So, what you are doing for this step! Basic concept for a PM, right, create a WBS list base on the high level solution and timeline requirement will help to line up the milestones schedule and draft costing (human resource, other resources, integration cost and all the other costs that might rise during the Risk identify process will add up into the cost and schedule). I'm talking a lot about PM, BA, SA roles, seems we're doing with traditional RUP, waterfall process, how about Agile, no more PM, right! Yes, no more traditional manager but who will take care for the budget and schedule of release, PO, he is the one who will own those stuffs so you can say PO or PM, who is the one responsible for the budget and schedule of the outcome software will be the main stakeholder of this step.
- Project form up. This can be a not involved step but you have to prepare and facilitate all the project infrastructure and facility such as project team, members, hardware resources, working environment, process, training plan, procurement third party resource ... It's an easy missing step because when you do the cooking, usually you just remember about the material for your dish but don't forget your frying pan, saucepan, ladle, chopping boar, stove etc ... you don't have an existing kitchen everywhere :D
Alright, it should be somewhere enough for the Initial phase. Move to the cooking, oh, yes, Implementation Phase.
- Detail design. So we already had the detail requirement, the high level architect then now is the step to break down the project work into doable/implementable pieces. We will need a Technical Architect here, this one is a detail technical person that has deep knowledge on the specific technology that we defined the software to be built up from the high level architect. The TA will break down the solution into systems, interfaces, modules, components, transactions ... then team members will start to perform the design of each unit component for the implementation/coding. Again, come back to the Agile terminology, now you can see a lot of full-stack developer, this is another trend to build up a mature Agile team from requirement capturing/understanding (you don't have to form up a very formal requirement set at early stage) to design, implement then testing (doing the task of automation engineer in test).
- Implementation. This is a biggest part of the project, although it's just a simple work, IMPLEMENTATION but how the project is implemented is the whole concept how the PM manages the project (obviously there are other workflow competencies). This step the team will base on the requirement, design then implement the features and unit test. The most important is the integration planning when integrate the modules, components. I don't mentioned a lot on other aspects of the project will impact into the project such as Change Control Management, Risk Management, Procurement Management ... because this article is focus on SDLC but not on Project Management process.
- Testing. Some might take this step into a phase because testing is also a big area that we have to explore, there are multiple types of testing from the level of testing from component/function, to integration, system testing to regression testing, then non-functional testing, load/stress testing, harden testing, performance testing or some can define as white/black box testing. Then we have different ways to perform testing such as manual testing, automation testing. The testing process also applies some phases too, based on the requirement and solution, we will define the test bed, test suite then test cases. From those artifacts, the most cases, the integration/regression will be implemented for automation to reduce the testing effort. Please also note an important of testing step so there is an implementation process that focus into quality result called Test Driven Implementation.
- Packaging. This step can be in implementation or in the next phase, I put it here as we might have big effort to implement the build script for the automation build and packaging process (as part of CI/CD process)
So the next phase is Transition Phase.
- Deployment. This step is to deploy the package into Production environment. We can say from this step, the output of the Implementation phase is a shippable delivery (Agile term for an outcome of each Sprint). Involve into this step we have to take into account about some concepts that will be used for after production support such as cut-over planning, cut-over time, disaster recovery plan, production data migration ... Those items are used when:
- Production data migration: when we have new release, upgrade that might change the data structure or design from the current system into new deploy system, we have to plan for this data migration, data backup or data loosing ...
- Cut-over plan: production environment mostly can't be in outage so we have to plan for this cut-over time (less accesses and temporary server ...), announcement on the cut-over for the changes ...
- Disaster recovery plan: in case the deployment failure, we have to have a clear plan how to restore the service as normal in minimal timeframe without data lost
Please note here for the CI/CD (DevOps) process, there are 2 definitions of CD: Continuous Delivery vs Continuous Deployment, in which Deployment is an advance of Delivery. The Delivery is defined for the automation process until the package is ready for deployment which will be manual deploy afterward where the Deployment is the full automation until the product is live on production (usually on Cloud/microservices architecture)
- Training/handover and support. This is where we will train/handover the product to the owner of the operation team of this software. Usually, this training plan should be performed with a pair of sender and receiver as follow. The sender will prepare and training all the basic, guideline, how to documents to the receiver. The support, hand-on period will have 2 phases, Driver phase, the sender will do all the support tasks to let the receiver observe and study on real activities on the system. Monitoring phase will switch the roles, the sender will monitor the performance and guide the receiver during the hand-on performance.
So after is phase, usually the software project is completed, which the project scope usually was defined for the software development. Rarely, some SOWs might have the addendum with X years of software maintenance included but almost the cases the maintenance project will be separately. The next phase as you can guest, it's Maintenance Phase.
- Support and fix defect. This step is parallel with the step below, this is the action to support end user how to use the new system correctly, perform the fixing defect on production usage. For this Maintenance phase, we have to have a ticket system in order to define and track the flow of an incident from multiple levels of support, we should get the knowledge of ITIL service to perform the service support and service delivery for this phase. There are some terms and concepts involve into this phase such as:
- SLA - Service Level Agreement: this is an agreement on the responsiveness of the service provider to the end user. There are some generic definition we can hear like Diamond, Gold, Silver, Bronze service but it will be various in the detail requirements, the measurement detail should be 24x7, 24x5, 16x7, 16x5, 8x5 ... Response (acknowledge) time vs Resolution time: response time is the period between the incident ticket was submitted until the service agent acknowledge and confirm this incident is being worked. Where Resolution time is the period until the fix is presented into production.
- Multi-tiered technical support (tier or level): Tier 0 is the FAQ or wiki knowledge base. Tier 1 is customer support like call agent to interact directly with end user to gather all the information about the incident. Tier 2, this is more technical layer with expertise on the support system that can isolate the module, component of the incident on the code base. Tier 3 is the support engineer which will perform the code fixing on the incident that was pointed by Tier 2 person. Tier 4 is the escalation layer which can be the 3rd party vendor who develop the product.
- Enhancement and Change Request. This is also a part of the Maintenance phase which will apply the same process as incident support as mentioned above, however, this will be a new feature of the current system which might be a small change (can be handled by a ticket) or an enhancement project can be handled by Tier 3 group. As you can see, when we talk about project, then the enhancement or change request project will be handled like a subproject of the maintenance phase or even force a new project to be controlled separately. Again, this will be Project Management concept so I don't mention this in detail here.
In summary, there are 4 phases of the SLDC:
Initial Phase => Implementation Phase => Transition Phase => Maintenance Phase
It's quite a bit on a SLDC detail, again, this is not totally the correct definition or explanation but this is my knowledge and understanding, you can refer to this article for your information. You can find a standard definition here which has the same content with different steps.
I will have another post to talk about some items about software process, Development vs Maintenance support ...
Later!
Comments
Post a Comment