Thumbnail for 5.1 CCPDS-R A Case Study by Neil gogte Institute of Technology

5.1 CCPDS-R A Case Study

Neil gogte Institute of Technology

16m 7s2,477 words~13 min read
Auto-Generated

[0:05]Welcome back, students. So, in this lecture, we'll try to start with a simple case study. So, this case study is, this case study is given by the author of your book. So, this case study is a truly built model which was built for your US Air Force, and CCPDS-RA is the case study what we are going to discuss now. So, what is this CCPDS-RA? It stands for Command Center Processing and Display System. So, what is the use of this system and why was this built because it was a command system which was built for your US Army, and this is a commanding system which is going to have different parts of your software. So, this is entire project is going to have your system engineering process, and how your hardware was procured in order to create a display unit and warning system, and at the same time what software, how your software deployments were done or developments were done, and which in how many phases your software development was done. All these three major activities were taken into this CCPDS-RA. So, only these three systems that is your system engineering, your hardware procurement and your software development. Only these three different phases, they have taken around three, what is, 1/3 of your total cost. That is vested on your project. So, this is a project of around two, two million dollars at the period of, right in the period of 1987. And the total time taken for this particular project development is seven years, so the total time spanned around 1987 through 1994. So, each and every module here consists of different set of lines, only the common subsystem that is designed in your model, it consisted of around 3 lakh 55,000, 55,000 lines of source codes in your project. Right, so what is this project going to have? So, it is basically going to have three different subsystems as already said. So, first subsystem is your common subsystem, and this particular subsystem is going to have around 3 lakh 55,000 lines of code, and this is responsible for developing, like this subsystem is responsible for creating a reusable architecture. Second is processing and display subsystem. This is responsible for creating a display unit to the Army Majors here, and this particular subsystem it consisted of around 2 lakh 50,000 source lines of code, and the last one is your Stratcom subsystem. So, what is the use of this Stratcom subsystem is, it is responsible for starting your system here. And the total lines of code it took around is 4 lakh 50,000 lines of code here, and this is going to provide a warning system to both the missiles and your ground level. Right, so it is responsible for your force management compatibility. So, your software acquisition process actually it consisted of this is the overall architecture of your CCPDS-RA. So, we have three subsystems, and these three subsystems were majorly divided into two different phases. So, before we try to understand what is the use of going with this case study. Sorry for that. So, we need to understand what is this, like why only we go with this particular case study. There are number of software projects which helps you in understanding how your software project models work, but this case study is going to be help you is this is going to help you out in understanding how practically a software was built, what are the practical sequence of steps what were executed, how many phases your project was done in how many iterations your project was completely built. So, complete information related to this particular project is provided under this case study here. And at the same time, this is a well documented structure, in spite of number of documents, you can take this as a baseline to work with how you work with your projects. Right. So, here your software acquisition related to your CCPDS-RA subsystem, it actually consisted of two phases now. So, first phase is your CD phase. CD stands for your console development phase.

[4:17]So, what is this console development phase going to do is it will help you in developing a business case study related to how your console works. So, this is your console development. And second FSD phase, FSD phase stands for your full scale development phase. So, this CD phase itself, it consisted of a schedule of around 12 months, and the basic outcomes of this particular CD phase is you are supposed to create a reusable architecture by using your software development plans, by exercising different architectures that are already available in your project. And what, by using the system software engineering tactics. So, this console development was supposed to be developed. So, here you are supposed to, the aim of this phase was they were supposed to come up with a reusable architecture here. That is how your console development phase actually works, and when you go with this FSD phase. So, this is going to work with as I already said, your system specifications and a reusable architecture, this particular phase is going to work with. And when you go with this CD phase, so this is going to work with your technical architecture. Technical architecture, and it has spanned around 48 months, so only these two phases have taken around three years of time in order to develop your project. So, here this particular project consisted of different milestones at each and every phase, and this is going to have your, like other three parts of your project development. So, only your console development phase is acting as your inception phase here, you take down your requirements and requirements related to your project and start working with the architecture here. But other three parts of your project works with, other three phases of your project works with your FSD phase here. So, this is going to act as your elaboration, construction and transition phases, all these were implemented under this FSD phase here. Right. So, this actually consisted of two different architectures and six different milestones and all the milestones were developed as per your system development plan itself. So, basically there are four different use cases that are available in your project, so it basically focused on four different use cases. These use cases will help you in were helping us in understanding how your project was elaborated and developed, demonstrated. So, this software architecture as your CCPD-RA console development phase, it works on this software architecture. And this will help you in creating the skeleton how your project was designed, and a total of 4,163 source lines of code were created in order to work with this console development. And it is going to work with different prototype components available. So, basically, this particular phase, it is working with three different milestones, and at each and every milestone there are number of actions that are supposed to be executed. So, targeting around 30 different action items were resolved during the total development here. And when you go with this production phase. So, around 11 documented or clearly documented documents were proposed as per the proposed artifacts, and these were given at each and every reviews of your project. And depending on the requirement several, several improvements were made to your project, and at the same time different tools were also used, and they were also identified like advanced tools were also identified in this particular project development. So, these are the different plans that were included in these two architectures what we have discussed as your CD and FSD. Right. Okay. So, what is the use of this particular project here? So, first, whenever they started with, how, how the this project organizations will help you in understanding how the project was organized throughout your CCPDS-RA development here. So, this particular CCPDS-RA development, it actually replaced this TRW artifacts here. So, this actually they consisted of four different responsibilities. Project during this project development, the project organization were done by using this four responsibilities. So, first responsibility is they are supposed to understand like analyze and specify what are the different requirements of your project here. Depending on the requirements only your project organization was done, and second they have defined and developed the top level architecture. So, this top level architecture we take it as the broad architecture which was designed, and based on the requirements changes in your requirements, this top level architecture could be modified. But this top level architecture was built by defining and developing the different requirements of your project. And next, they started planning this FSD phase here, so as we already said, FSD phase, it is consisting of three different phases of your project life cycle. So, based on the development activities requirement, this FSD phase was started with development, and next configuring the process and developing your environment. So, on which environment your project was supposed to be done deployed, and it is supposed to be executed that was configured successfully, and these are the basic requirements, and the last and basic requirement is they should have trust among themselves like different parts of people were working with their project. So, they were also they thought of generating a trust among themselves, so that the stakeholders will have a win-win situation here. So, that was also established, the different win-win relationships were established among different people along with the stakeholders, and based on these requirements and responsibilities the project development has come into force, or it has proceeded. Right, so we will try to understand what is this common subsystem product looks like. Right. So, this common subsystem product consists of different architectures here. So, what is this is, it consists of different parts first. First is your network architecture services part, so this actually works with the network related topics, and second is your system services, what services your warning system should provide, like it should provide your details on your warnings, warnings to the users, on your missiles, which particular missile is supposed to be launched, so all these systems related services were provided. Third is your display coordination. So, third unit consists of how we are how you are going to display your unit, like how you are going to project your data onto your display consoles, that is what your display coordination product consists of. And fourth is your test and simulation phase, so here you are going to in this particular part they are going to test and simulate under different environment, and last they go fifth, they go with common mission processing. So, what is this common mission processing doing is, it is going to find how your missile is how your missile warning system was working with, and last is your common communication system. So, this common communication systems, it actually consists of the different external environments or interfaces that are available in communication along with your missile system with this particular warning system. So, these are the different parts of your common subsystem here. Right. So, here this is the schedule given at each and every phase throughout your FSD and CD part. So, if I take it, around 100 people are available in your project.

[12:20]So, the schedule is provided around, as per our previous example, the schedule for your CCRA and FSD only two parts were taken around three years. So, throughout this particular schedule, so your common system were improvements in your common system were given in this form, and at each and every phase, how many people were working with and how many people have started with at each and every phase, and how they are divided is given in this particular hierarchy diagram. Say, say for example, in your CD phase around 20 people were working on your inception phase, and in your FSD phase around 23 people were working on your elaboration phase. So, all put together, there are 43 members and they were divided into this particular format in the same case with your 82 people which are construction phase, they were working with your development process here.

[13:17]So, this is how your projects were actually, this FSD, CCPDS-RA project was development was divided. Right. So, this is how your FSD project organization were completely divided, and the complete roles and responsibilities of your FSD project organizations. So, here this particular project management, under your project management, you have two main roles, one is your chief engineer and your administration, and under this you also have three different roles again, software engineer, development and tester. So, each and every roles were clearly defined before they started working with the project, and the roles you can find out here. Right.

[13:50]So, we will go with, fine. So, this, sorry. So, this is about your project development, or your project roles and responsibilities. So, here throughout this software architecture, they proposed to use make use of a project language called as ADA language. So, while proposing this ADA, they identified that why only ADA is supposed to be used and why not other programming languages, they have come across different problems with this particular program language. But in spite of identifying this problems, as per the project management requirements, only ADA was taken into consideration to develop your project code, and this programming language was enforced to work with your project design model. And they have worked with all the tasks related to your project development, were developed only by using this particular language. Right. So, throughout your project development, like six different what builds were done, or six different releases were made, and at each and every phase, or at each and every build, one or the other improvements were made and finally at the sixth, sixth build, a final running model was developed and introduced to the, like it was deployed at the users end. Right. So, at each and every phase, different milestones were taken into consideration and these milestones were answered, and if they were unable to answer them, they were replaced with some other milestones or artifacts, and your project development was taken, and this particular picture will give you an overview of what are different process, milestones and schedules related to your project. So, these are, already said, there are around six builds were done, and final build was a successful build here. So, your success means it is in terms of like your project development and along with satisfying your stakeholders and users here. Right. So, that is all about this particular use case, so there is so much about this use case, we'll discuss about your next topic in your next class. Thank you.

Need another transcript?

Paste any YouTube URL to get a clean transcript in seconds.

Get a Transcript