Part I – The fundamentals Chapter 1 SDLC and Project documentation What does this book target The prime goal of this book is to make a programmer comfortable to work practically on C# projects adhering to proper software quality processes. In my childhood times I wanted to learn cycling. That’s because all the village girls liked boys who can ride cycle : - ). So I some how managed to get myself in my village cycle training school, it was a four day course. In the cycle training school I was taught theory for three days and then on the fourth day I touched the cycle. But I was never confident enough to drive the cycle independently. But one fine day one of my good friend just made me sit on the cycle and continuously made me drive the cycle for three hours. LOL!!! I learnt it. The same holds true for Software field one actual implementation is 1000 times worth than big GURU talks. But there is one more important thing – Software quality process. I did learn riding the cycle but for one week continuously I was struggling to manage brakes, turns etc. In short I learnt to ride the cycle but not in a controlled and quality manner. That’s a different thing I learnt to control the cycle over a period of time. So the second aspect this book will target is not only to enable you practically but in a controlled fashion so that you give quality code rather than quantity code. Note: - The biggest difference between an ok programmer and good programmer is quality coding. So here's my equation for this book. THIS BOOK = INSTANT PRACTICAL + PROPER QUALITY SOFTWARE PROCESS The growth of a software professional Page 13 of 215
If you are self taught programmer or working in a company which is not process oriented the title of this section can sound a bit bureaucratic to you. A good software product other than source code has proper documentation and process at place. Every young developer in his initial part of the software career is hot blooded and full of enthusiasm. The only goal he has in his mind is to complete the project. For these kind of young developers source code is the most important section in the complete project. As time passes by and the young developer starts gaining experience depending on the type of the company and his number of year of exp his view point changes. As the developer becomes senior source code becomes an insignificant entity and documentation forms the most important part of the project from his perspective. Below is the breakup and view point depending on maturity level of software professional. 0-2 Years of experience: - Developers having experience in this range give importance to source code. They take pride and enjoyment to write cryptic and heroic logic. Developers falling in this category think documentation as bureaucratic. If not controlled properly they rarely will think to even comment codes. But yes software professionals in this experience range have great technical enthusiasm. They love to get involved technically. 3-5 Year of experience: - Software professional in this category have lot of maturity in technical section. They take pride in architecture work of the project. In fact many of the developers would like to see th emselves as architecture in the coming times. That’s a different thing as they get to more senior position they want to see themselves as project managers rather than in to technical. Software professional in this range think source code with proper comments and technical documentation as the most important deliverable. They have less focus on project planning, estimation and testing. 6 - 8 Years of experience: - Software professional in this experience range give importance to technical documentation, estimation and source code. But they are bit soft when it comes to project planning and testing. 9 and above Years: - This is the time he becomes a complete senior (he becomes a bit fat). Source code deliverable becomes one of the smallest entities of the project. Planning, monitoring, People issues, escalation and estimation become prime focus for him. He starts following processes like CMMI and SIX SIGMA religiously. From this book i am not trying to communicate that estimation, planning or project management is not a important part. But as people become seniors why is that they start loosing technical touch. When we know technical forms an important aspect of software projects. In short the right proportion between management and technical is important. Wh en a software professional starts his career technical is the only thing for him and when he is at his peak management is everything. If a professional makes a proper balance of both these entities we have the MR Perfect with us.....And I know there are still many MR Perfect in the software industry or else we would not have come so far. Page 14 of 215
Figure 1.1 : - Viewpoints of software developer Above figure shows how senior and junior view project deliverables. Projects in this book will have all the above documents which will give us a complete view of the project. If we do not have documentation in project you will probably complete the project but when new people join knowledge transition becomes a huge task. The biggest advantage of documentation is that the project becomes resource independent and which is a huge success for any project. I know how difficult it is to convince juniors and developers working in small scale software house the importance of documentation and proper process to complete a project. How many times it has happened that you wanted to change your project and your project manager did not allow you?. Yes because he knew that you are a hero of the project and your leaving will create him problems. So first thing never be a hero on a project rather work in co-coordinated fashion and make project independent of you. Page 15 of 215
The best way to attain independency in project is by proper documentation. Clear cut documentation makes new developers to join the project in much easy fashion and you can move to new heights in the organization. Now two cents!!!! For the seniors who do over documentation the project ;-). I still remember one of my seniors who told me to document how a developer should behave in the project. The above said document is related to project, but if it is not there it will not affect the project in any way. In short introduce documents in project which are really needed rather than just pushing something for namesake. SDLC (Software development Life Cycle) Every activity has a life cycle and software development process is not an exception for the same. Even if you are not aware of SDLC you still must be following it unknowingly. But if a software professional is aware about SDLC he can execute the project in a much controlled fashion. One of the big benefits of this awareness is that hot blooded developers will not start directly execution (coding) which can really lead to project running in an uncontrolled fashion. Second it helps customer and software professional to avoid confusion by anticipating the problems and issues before hand. In short SDLC defines the various stages in a software life cycle. But before we try to understand what SDLC is all about. We need to get a broader view of the start and end of SDLC. Any project started if it does not have a start and end then its already in trouble. It’s like if you go out for a drive you should know where to start and where to end or else you are moving around endlessly. Figure 1.2 : - Entry, SDLC and Exit in action Above i s a more global view of the how the start and end of SDLC. Any project should have entry criteria and exit criteria. For instance a proper estimation document can be an entry criteria condition. That means if you do not have a proper estimation document in place the project will not start. It can be more practical, if half payment is not received the Page 16 of 215
project will not start. So there can be list of points which needs to be completed before a project starts. Finally there should be end of the project also which defines saying that this is when the project will end. For instance if all the test scenarios given by the end customer is completed that means the project is finished. In the above figure we have the entry criteria as an estimation document and exit criteria as a signed document by the end client saying the software is delivered. Below is the figure that shows typical flow in SDLC which has five main models .As per use developers can select model for their project. Waterfall - Big Bang and Phased model . Iterative - Spiral and Incremental model. Waterfall Let’s have a look on Waterfall model which is basically divided into two subtypes: - Big Bang waterfall model. Phased waterfall model. As the name suggests Waterfall means flow of water always goes in one direction so when we say waterfall model we expect every phase/stage is freezed. Big Bang waterfall model The figure shows waterfall BigBang model which has several stages and are described as below: - Requirement stage: - This stage takes basic business needs required for the project which is from a user perspective so this stage produces typical word documents with simple points or may be in a form of complicated use case documents. In this book we will be using use case documents to describe this stage. Note: use case are explained in detail in UML section Design stage: - Use case document / requirement document is the input for this stage. Here we decide how to design the project technically and produce technical document which has Class diagram, pseudo code etc. Build stage: -This stage follows the technical documents as an input so code can be generated as an output by this stage. This is where the actual execution of the project takes place. Test stage: -Here testing is done on the source code produced by the build stage and final software is given a green flag . In this book we will have a test plan documents for this stage. Deliver stage : - After succeeding in Test stage the final product/project is finally installed at client end for actual production. This stage is start for the maintenance stage. Page 17 of 215
Figure 1.3: - SDLC in action (Waterfall big bang model) In this model, it is assumed that all stages are freezed that means it’s a perfect world. But in actual projects such processes are impractical. Phased Waterfall model In this model the project is divided into small chunks and delivered at intervals by different teams. In short, chunks are developed in parallel by different teams and get integrated in the final project. But the disadvantage of this model is there is improper planning may lead to fall of the project during integration or any mismatch of co-ordination between the team may cause huge failure. Iterative model Iterative model was introduced because of problems faced in Waterfall model. Now let’s try to have a look on Iterative model which also has two basic subtype as follows: - Incremental model Page 18 of 215
In this model work is divided into chunks like phase waterfall model but the difference is that in Incremental model one team can work on one or many chunks which was unlike in phase waterfall model. Spiral model This model uses series of prototype which refine on understanding of what we are actually going to deliver. Plans are changed if required as per refining of the prototype. So every time in this model refining of prototype is done and again the whole process cycle is repeated. Evolutionary model In Incremental and Spiral model the main problem is for any changes in between SDLC cycle we need to iterate through the whole new cycle. For instance, During the final(Deliver)stage customer demands for change we retreat the whole cycle again that means we need to update all the previous (Requirement, Technical documents, Source code & Test plan) stages. In Evolutionary model, we divide software into small units which can be earlier delivered to the customer’s end which means we try to fulfill the customer’s needs. In the later stages we evolve the software with new customers needs. V-model This type of model was developed by testers to emphasis the importance of early testing. In this model testers are involved from requirement stage itself. So below is the diagram which shows how for every stage some testing activity is done to ensure that the project is moving as planned. For instance, In requirement stage we have acceptance test documents created by the testers. Acceptance test document outlines that if these test pass then customer will accept the software. In specification stage testers create the system test document. In the coming section system testing is explained in more elaborate fashion. In design stage we have integration document s created by the testers. Integration test documents define testing steps of how the components should work when integrated. For instance you develop a customer class and product class. You have tested the customer class and the product class individually. But in practical scenario the customer class will interact with the product class. So you also need to test is the customer class interacting with product class properly. In implement stage we have unit documents created by the programmers or testers. Lets try to understand every of this testing phase in more detail. Unit Testing Page 19 of 215
If you are self taught programmer or working in a company which is not process oriented the title of this section can sound a bit bureaucratic to you. A good software product other than source code has proper documentation and process at place. Every young developer in his initial part of the software career is hot blooded and full of enthusiasm. The only goal he has in his mind is to complete the project. For these kind of young developers source code is the most important section in the complete project. As time passes by and the young developer starts gaining experience depending on the type of the company and his number of year of exp his view point changes. As the developer becomes senior source code becomes an insignificant entity and documentation forms the most important part of the project from his perspective. Below is the breakup and view point depending on maturity level of software professional. 0-2 Years of experience: - Developers having experience in this range give importance to source code. They take pride and enjoyment to write cryptic and heroic logic. Developers falling in this category think documentation as bureaucratic. If not controlled properly they rarely will think to even comment codes. But yes software professionals in this experience range have great technical enthusiasm. They love to get involved technically. 3-5 Year of experience: - Software professional in this category have lot of maturity in technical section. They take pride in architecture work of the project. In fact many of the developers would like to see th emselves as architecture in the coming times. That’s a different thing as they get to more senior position they want to see themselves as project managers rather than in to technical. Software professional in this range think source code with proper comments and technical documentation as the most important deliverable. They have less focus on project planning, estimation and testing. 6 - 8 Years of experience: - Software professional in this experience range give importance to technical documentation, estimation and source code. But they are bit soft when it comes to project planning and testing. 9 and above Years: - This is the time he becomes a complete senior (he becomes a bit fat). Source code deliverable becomes one of the smallest entities of the project. Planning, monitoring, People issues, escalation and estimation become prime focus for him. He starts following processes like CMMI and SIX SIGMA religiously. From this book i am not trying to communicate that estimation, planning or project management is not a important part. But as people become seniors why is that they start loosing technical touch. When we know technical forms an important aspect of software projects. In short the right proportion between management and technical is important. Wh en a software professional starts his career technical is the only thing for him and when he is at his peak management is everything. If a professional makes a proper balance of both these entities we have the MR Perfect with us.....And I know there are still many MR Perfect in the software industry or else we would not have come so far. Page 14 of 215
Figure 1.1 : - Viewpoints of software developer Above figure shows how senior and junior view project deliverables. Projects in this book will have all the above documents which will give us a complete view of the project. If we do not have documentation in project you will probably complete the project but when new people join knowledge transition becomes a huge task. The biggest advantage of documentation is that the project becomes resource independent and which is a huge success for any project. I know how difficult it is to convince juniors and developers working in small scale software house the importance of documentation and proper process to complete a project. How many times it has happened that you wanted to change your project and your project manager did not allow you?. Yes because he knew that you are a hero of the project and your leaving will create him problems. So first thing never be a hero on a project rather work in co-coordinated fashion and make project independent of you. Page 15 of 215
The best way to attain independency in project is by proper documentation. Clear cut documentation makes new developers to join the project in much easy fashion and you can move to new heights in the organization. Now two cents!!!! For the seniors who do over documentation the project ;-). I still remember one of my seniors who told me to document how a developer should behave in the project. The above said document is related to project, but if it is not there it will not affect the project in any way. In short introduce documents in project which are really needed rather than just pushing something for namesake. SDLC (Software development Life Cycle) Every activity has a life cycle and software development process is not an exception for the same. Even if you are not aware of SDLC you still must be following it unknowingly. But if a software professional is aware about SDLC he can execute the project in a much controlled fashion. One of the big benefits of this awareness is that hot blooded developers will not start directly execution (coding) which can really lead to project running in an uncontrolled fashion. Second it helps customer and software professional to avoid confusion by anticipating the problems and issues before hand. In short SDLC defines the various stages in a software life cycle. But before we try to understand what SDLC is all about. We need to get a broader view of the start and end of SDLC. Any project started if it does not have a start and end then its already in trouble. It’s like if you go out for a drive you should know where to start and where to end or else you are moving around endlessly. Figure 1.2 : - Entry, SDLC and Exit in action Above i s a more global view of the how the start and end of SDLC. Any project should have entry criteria and exit criteria. For instance a proper estimation document can be an entry criteria condition. That means if you do not have a proper estimation document in place the project will not start. It can be more practical, if half payment is not received the Page 16 of 215
project will not start. So there can be list of points which needs to be completed before a project starts. Finally there should be end of the project also which defines saying that this is when the project will end. For instance if all the test scenarios given by the end customer is completed that means the project is finished. In the above figure we have the entry criteria as an estimation document and exit criteria as a signed document by the end client saying the software is delivered. Below is the figure that shows typical flow in SDLC which has five main models .As per use developers can select model for their project. Waterfall - Big Bang and Phased model . Iterative - Spiral and Incremental model. Waterfall Let’s have a look on Waterfall model which is basically divided into two subtypes: - Big Bang waterfall model. Phased waterfall model. As the name suggests Waterfall means flow of water always goes in one direction so when we say waterfall model we expect every phase/stage is freezed. Big Bang waterfall model The figure shows waterfall BigBang model which has several stages and are described as below: - Requirement stage: - This stage takes basic business needs required for the project which is from a user perspective so this stage produces typical word documents with simple points or may be in a form of complicated use case documents. In this book we will be using use case documents to describe this stage. Note: use case are explained in detail in UML section Design stage: - Use case document / requirement document is the input for this stage. Here we decide how to design the project technically and produce technical document which has Class diagram, pseudo code etc. Build stage: -This stage follows the technical documents as an input so code can be generated as an output by this stage. This is where the actual execution of the project takes place. Test stage: -Here testing is done on the source code produced by the build stage and final software is given a green flag . In this book we will have a test plan documents for this stage. Deliver stage : - After succeeding in Test stage the final product/project is finally installed at client end for actual production. This stage is start for the maintenance stage. Page 17 of 215
Figure 1.3: - SDLC in action (Waterfall big bang model) In this model, it is assumed that all stages are freezed that means it’s a perfect world. But in actual projects such processes are impractical. Phased Waterfall model In this model the project is divided into small chunks and delivered at intervals by different teams. In short, chunks are developed in parallel by different teams and get integrated in the final project. But the disadvantage of this model is there is improper planning may lead to fall of the project during integration or any mismatch of co-ordination between the team may cause huge failure. Iterative model Iterative model was introduced because of problems faced in Waterfall model. Now let’s try to have a look on Iterative model which also has two basic subtype as follows: - Incremental model Page 18 of 215
In this model work is divided into chunks like phase waterfall model but the difference is that in Incremental model one team can work on one or many chunks which was unlike in phase waterfall model. Spiral model This model uses series of prototype which refine on understanding of what we are actually going to deliver. Plans are changed if required as per refining of the prototype. So every time in this model refining of prototype is done and again the whole process cycle is repeated. Evolutionary model In Incremental and Spiral model the main problem is for any changes in between SDLC cycle we need to iterate through the whole new cycle. For instance, During the final(Deliver)stage customer demands for change we retreat the whole cycle again that means we need to update all the previous (Requirement, Technical documents, Source code & Test plan) stages. In Evolutionary model, we divide software into small units which can be earlier delivered to the customer’s end which means we try to fulfill the customer’s needs. In the later stages we evolve the software with new customers needs. V-model This type of model was developed by testers to emphasis the importance of early testing. In this model testers are involved from requirement stage itself. So below is the diagram which shows how for every stage some testing activity is done to ensure that the project is moving as planned. For instance, In requirement stage we have acceptance test documents created by the testers. Acceptance test document outlines that if these test pass then customer will accept the software. In specification stage testers create the system test document. In the coming section system testing is explained in more elaborate fashion. In design stage we have integration document s created by the testers. Integration test documents define testing steps of how the components should work when integrated. For instance you develop a customer class and product class. You have tested the customer class and the product class individually. But in practical scenario the customer class will interact with the product class. So you also need to test is the customer class interacting with product class properly. In implement stage we have unit documents created by the programmers or testers. Lets try to understand every of this testing phase in more detail. Unit Testing Page 19 of 215
ليست هناك تعليقات:
إرسال تعليق