software project management - gehu cs/it deptt web viewsoftware economics allows us to manage them...

VII Semester – Software Project Management

Software Project Management

Software Economics:

The primary function: The primary reason behind the implementation of Software Economics in such a studious manner is to facilitate a substantial increase in the “marginal cost” for the attainment of a contract, project development, project deployment and project maintenance. This, to be honest is no exception in the field of Software Project Management, since all the parts of the entire process of building a project and deploying it successfully, are managed by explicitly mentioned individual processes. The aforementioned reason behind the implementation of Software Economics is also the very reason for the existence of any kind of Project management in all the development and creation fields in all the businesses around the world.

What it helps us achieve?

Scarcity of Resources is a continual issue that will have to be constantly dealt with, during the course of any kind of Software Development. Software Economics allows us to manage them efficiently, from a purely financial perspective, because all said and done, after the basic technical requirements are met, the sole aim of the vendor or the contract holder comes down to maximizing the profits. Calculating the work hours for each resource and the project that one wishes to allocate them to, is all a part of the application of Software Economics on this front.

The other primary application of Software Economics, which forms the basis of a lot of the other business facets of a Software Project, is with respect to Estimations. The primary parameter, based on which, everything from the Contract bid to the line of the development of the Project is decided, is the Effort Estimation. Software Economics provides us all the primary data points needed to make the Effort Calculation or Estimation as accurate and effective as possible.

o This involves the process of counting function points, gathering and analyzing data, Software Metrics, Software Economics

ADDITIONAL TERMINOLOGIES – Helping you understand the nuances of Software Economics

Cannibalization – They say that business models for smaller companies are much simpler and the level of detailing that they need to take care of is much lower as compared to their bigger counterparts. One of the concepts that help the experts vindicate their statement is


cannibalization. This is the situation that bigger companies in all fields face, when multiple products in their portfolio coincide in terms of market space, they start fighting for space amongst themselves. This cannibalistic nature of the products of a company can be both beneficial and detrimental to the operational efficiency. The luxury car example discussed in the class best explains this. It is always for a company to decide, till when it wants to continue with a particular product even after it has been hampered by the concept of cannibalization, with the sole aim of utilizing its resources in the most efficient manner.

Diseconomies – These are the forces that cause a company, an organization or even governments, to produce goods, services or regular products at a higher per unit cost.

Diseconomies of Scale – This is an extended definition for Diseconomies. The “Scale” part adds to the earlier definition and expands it to – “The forces that cause a company, an organization or even governments to produce goods, regular products or services at a higher per unit costs, with the forces coming into existence because of the growth in the size of the Producing Entity.In other words, the factors which come into existence because of the size of the company becoming larger, and then cause the per unit price of the products being developed to shoot up, are called the diseconomies of scale for that field.

Diseconomies of Scale for Software Engineering – So, as per the definitional information provided earlier, there are a number of Diseconomies of Scale for Software Economics and some of them have been listed down here for you. Keep in mind that the information provided alongside is extremely logically related and can be derived by anyone without any assistance from any outside sources:

o The number of fixed costs is considerably lesser than the number of variable costs: Since a major chunk of the costs associated with modern day Software development are variable and not fixed, appreciation on that front goes haywire as the size of the project increases. The “variable” component of these costs is in direct proportion with the size of the project, which means that there will be an immediate increase in these costs as soon as the size of the project increases even marginally.

o The communication between members of the project becomes exponentially more challenging as the size of the project increases: More members in a project, or essentially, just a bigger project itself implies that the setting up of communication channels with one to one mapping will cost a lot more, if compared to the costs that will be incurred in a smaller project.

o Multiple logical paths grow in a non-linear manner as the project size increases: As the project size increases, the number of logical paths in which a project can grow increases exponentially. This, in simple words, means that when you have the solution finding of a bigger problem, the ways to achieve that go from one to many, which means that shortlisting a single solution for it will be more time and resource consuming, and at times might not be viable at all. This effectively translates into a more complex architecture for the project solution which again in turn, pushes the /unit cost exponentially.


o Interrelationship requirements between different modules increases geometrically as the size of the project increases: The size of the project has a tremendous impact on the approach being taken to achieve the optimum solution for the problem statement. While the goals to be achieved remain the same, the methodology will get altered and one of the most common changes in the methodology is that of adopting a modular approach. The catch with a modular approach is that the interrelationship between the different modules becomes extremely important and keeping a system in place for that, is a definite overhead as compared to a singular approach.

SOFTWARE ECONOMICS: An amalgamation of various fields

Like we discussed before, Software Economics is more of a branch of Economics that deals with Software rather than being a branch of Software Project Management that deals with Economics. Since the very foundation of the field is based on a different science all together, it would be only logical to believe that there is a possibility of some other fields also being involved in the basic definitional formation. You can think of this as an application of Murphy’s Law, since there is a possibility of other fields being involved then there will be an involvement on that front, and that is exactly how it is.

Software Economics is not just a single discipline, as its practical avatar takes a lot of inputs from a lot of lines, to make the output extremely efficient. The different disciplines involved are:

Psychology: It involves the study of behavior patterns and expectation levels at the levels of the resources employed for a project, and this in turn allows us to implement the theory of “What gets rewarded gets done”. The theory allows us to set rewards related to the timely completion of specific tasks depending upon the priority levels listed down. The rewards may involve recognition of any kind, monetary incentives or even promotions (for high priority and high complexity tasks). The setting up of fixed rewards as per a strict delivery schedule makes sure that the employees stay motivated throughout which helps push their quality and efficiency upwards.

Social Psychology: The only difference that a comparative analysis of Social Psychology and Psychology with respect to Software Economics, could yield, is that in the case of Social Psychology, the picture painted is much more holistic. This has got more to do with the complete behavioral patterns of an individual with respect to an organization and understanding the problems faced by them. It also encompasses an analysis of factors such as peer pressure and work environment, which in turn pushes for higher work efficiency of the employees making the outlook of the project on an economic front extremely positive.

Organizational Behavior: The structure of the organization itself plays an extremely crucial role in deciding how efficiently the project deliverables are pushed on the table as per the expected timeline.


Economics: This comes as no surprise as this is the basis of everything that happens under the umbrella of Software Economics. All businesses are at the end of the day aimed at making the maximum profit and ensuring justifiable distribution of the profits amongst the deserving people, and all of this falls under the ambit of Regular Economics.

Statistics: This is an essential part of all the calculations that are a part of Software Economics. This involves effort estimation and all the billing and bidding calculations that eventually tell the Project Holder the actuals concerning the money involved.

SOFTWARE COST ESTIMATION FACTORS:

The name of this subsection is self-explanatory. Software Metrics form the basic standards of measure Software Cost and Software Size as well. This helps the vendor optimize whatever deal is being materialized and also pull out the most efficient delivery schedules in the process of the completion of the project.

There are five basic factors that need to be considered when talking about software size or cost estimation

Size: The size of the software is one of the most important aspects of the entire process of Project Management, as it is used in all the phases’ right from estimation to final quality assessment. The most common metric for measuring the size of the project is SLOC or Source Lines of Code. In this case the length of the code is quantified in the form of the number of the lines that it entails which directly amounts to the size of the project. This method is particularly useful in the later stages of project development, as the majority of the code is already written, which makes for a quite accurate number as far as the size of the Software is concerned.

Another method that is extremely useful at the commencement phase of Software Development is that of counting the function points. In this method, each function is counted as a separate point; given that the functionalities covered have been broken down to their smallest units i.e. no clubbing is permitted.

Process: This section involves the processes that have been setup to drive the project to completion successfully. All of these processes are treated as separate data points and the count is accumulated to make it a part of the effort estimation calculation. This is one of the most important factors, as processes eventually prove to be the most time consuming and resource incentive parts of a project with the compulsion of not bypassing them at any cost attached to them. The situation is so because you cannot afford to have processes which prove to be overheads and at the same time you cannot afford to lose out on the processes which enforce the kind of quality standards that are desired off a project.

Personnel: Again, a very obviously named section. This is a factor that does not need to be worked very hard on, in terms of calculating the actual value. The number of people involved in


the project, as per appropriate weightage, can be directly counted as the value of PERSONNEL. The weightage being referred to here, is dependent on the level at which an employee is working and the criticality of the tasks that one is performing. For example, the weightage of a Program manager may be higher than that of a Defect Manager, because the latter’s part is more of a theoretical documentation portion as compared to the former, who has to actually supervise everything that needs to be done in order to attain 100% functional operation of the project.

Environment: The Environment subsection talks primarily of the hardware components that form the basis of the Environment that the project is built in. The count of the different components is what is considered to be the numeric value that comes out of this section. The level of detailing while listing the components can be decided upon by the management of the project.

Quality: Quality is quite frankly, one of the most important aspects of the entire process of Software Development, as it proves to be crucial not just on the technical front but also on the business front. Retaining a client and other important business objectives are dependent on how high your product is rated on the quality front. The ways to measure a project’s quality standards are quite varied, and change as per the management’s requirement. The standard way of quantifying a project’s quality standards is to chalk out a detailed quality parameter sheet, and then measure your project’s quality levels against those parameters periodically. The mapping and weightage combination generally used is one to one.

All of these factors are bound together by a mathematical expression that is supposed to give out an extremely accurate calculation of the Effort Calculation quantity, which proves to be ultimately beneficial for the entire process of Cost Estimation. The expression in which these factors are bound is:

Effort= (Size ^ Process)*Personnel*Environment*Quality

*This effectively translates into higher per line cost for software which is larger in size.

IMPROVING SOFTWARE ECONOMY – Trends and Improvement segments

Knowing Software Economics will not suffice when you’re in the industry. Just like the industry itself, the field of Software Economics is constantly evolving and all of it needs to be applied to actual production scenarios so as to increase output efficiency and make it more cost effective. Now the factors that we discussed in the previous segment will form an important part of this entire exercise of improving the monetary exposition of the project. Let’s have a look

SIZE: Now this is the most obvious target whenever you’re trying to optimize the finances involved in a project. The key improvement trend is the abstraction of component based


technologies. As we have witnessed before, the size of a project is directly related to the per line cost that it incurs, and to change that, there are a number of factors that can be considered.

Higher Order Languages (C++, Ada95, Java, .Net) can significantly reduce the size of the software, in terms of the lines of code that it entails. This helps the developer achieve the desired functionalities by using more predefined functions and spend less time on coding some basic functionality.

The Object Oriented approach helps optimize the code and the ways to achieve the desired functionality. This will apply to analysis, design and programming, thus making for a well rounded off solution that believes in a modular approach with the primary functionality being the clear target.

Commercial Components are an inevitable part of all software projects in the current times. The need for them arose because the companies developing these projects did not want to spend time developing components that were required for management at a macro or microscopic level. A simple example for this would be the usage of HPQC in all modern day testing projects. Instead of spending time on developing a proper Software Life Cycle management project, companies just opt for a commercial solution like it in the market, and thus get their work done faster and more efficiently. This proves to be a great time saver, pushes the quality standards several notches upwards, by saving a lot of overhead which in turn significantly reduces the size of the product.

PROCESS: The processes involved in the development of a software project will always be at the core of the kind of revenue that it generates. After the most obvious part of reducing the software size to improve the economy of the software, in comes the part that will be improved and worked upon over an extended period of time. The various factors viz.a.viz processes, that can be targeted to improve software Economy over time are

Methods and Techniques: The methods and techniques involved are the basic components of the process of a system. They are the most important cog in the entire process of achieving the highest possible efficiency, both in terms of resources and time consumption. The techniques might involve the entire development process, or any other phase of the entire project completion cycle. The way a cycle is handled and the kinds of practices to be followed during the completion of the project, has a tremendous effect on the quality of the product developed. Be it the versioning of a documents, change management, workflow creation, environment automation or anything to do with the way a functionality is supposed to be achieved , listing out the details of the process proves to be of utmost importance.

Iterative Development Process: Iterations are not just an unnecessary repetition of the same things performed in the previous cycle. They prove to be crucial in the cyclic reduction of workload of the resources and constantly having a check over the quality of a product being developed. Iterations allow the extremely important concept of base lining to be implemented. The detection and fixing of defects in an orderly manager is a direct result of


iterations. All this and the implementation of the concept of reusability (Documents and developed artifacts) make the iterative development process a fantastic tool for improvement on the Software Efficiency, hence the Software Economics front.

Maturity Levels: The level of maturity that a process attains will have a direct correlation with the number of reviews that it has been a part of. The reviews take place over a number of iterations and this causes them to be extremely cycle dependent. This in turn certifies a process to be more mature as the project progresses which is extremely valuable as far as the efficiency of the project completion is concerned.

o PERSONNEL: The personnel area becomes extremely important when the focus is on improving the software economics in a project development reference. The resources involved (people) are mainstay of the reasons behind making progress in the development process. The skill level of the people involved in the different processes has a direct impact on the productivity of the team. This makes it essential to involve the management in activities that target this directly. Personnel training, skill development workshops, team work development camps and other methods need to be implemented, so as to push for a major improvement target through this area. This creates a win-win situation for all the parties involved.

o ENVIRONMENT: The environment that a resource completes his tasks in proves to be the deciding factor, as far as productivity and economy is concerned. Time is money in Software Development, and all companies focus on getting more work done in the least possible amount of time. This optimum mix cannot be attained, unless the environment that the resources work on, are up to this task. This is why all modern day software development projects implement a lot of automations using different tools and technologies. Using integrated tools is now an extremely important part of the entire process of project planning, to an extent that clients even demand certain tasks to be done on certain tools. Making proper arrangements for a highly automated, state of the art environment thus carries tremendous potential as far as improvement on the Software Economics front is concerned

o QUALITY: Monitoring the quality on accuracy and performance fronts is absolutely inevitable in today’s days and times of Software Development. Performance and accuracy parameters being met on a module development level throughout different milestones in a development process, ensures that time and money are not wasted on correcting things and achieving benchmarks which could have been dealt with, at a much earlier stage. Quality management, in a way like testing, ensures that nothing has to be altered majorly at a crucial stage in the development process, and keeps the management assured that the project development is indeed moving in the right direction.


o REUSE OF SOFTWARE: The reuse of Software components and complete products forms the very basis of the development of any future versions pertaining to any particular application. This cuts down the cost of development tremendously, given that all the relevant artifacts and documentation of as previously developed product has been well managed. This reuse can be with respect to any module or facet of the entire development process, with some of them mentioned here.

Common Architectures Development Environments Operating Systems DBMS Networking Products Office Workload handling apps

UNIT II

This unit takes us into the details of the framework that has been setup to enhance the control that an organization has over the entire the process of Software Development. While we were dwelling over the superficial factors that majorly affect the S/W development process, we will indulge in detailing here onwards.

LIFE CYCLE PHASES:

The primary topic of discussion in this section will be the segregation of the SDLC in a pragmatic manner, on the basis of the activities carried out at different points in time in development. The line of discussion is primarily based on the inputs from Royce’s book of SPM, not because of the syllabi being in direct correlation, but because of the extremely pragmatic and accurate approach followed by him on this topic.

The level at which we’re starting at, allows us to segregate the entire life cycle into two major categories, in terms of phases, which are Engineering and Production stages. While there is no major explanation needed for these terms, as the names are more than self-explanatory and a little push on the logic front will specify the meaning very clearly, we will venture into slight details.

ENGINEERING STAGES: Basically referring to the design and synthesis phases. The parts of a life cycle where the entire project is designed and the way of completing it is formulated, are the ones that constitute the Engineering stages. It is typical of the Engineering stages that the work done is extremely unpredictable and the teams involved are generally small in number. The number and types of outputs are generally very subjective and the timelines associated are accompanied by a lot of cushioning.


PRODUCTION STAGES: The description of the section should be obvious by now, assuming that you’ve gone through the description of the Engineering stages. Since the formulation and designing is done in the Engineering stages, the other category has to include the actual work that will make the project see the light of the day. The productions stages are a conglomeration of all the phases that are directly linked to the actual ground development work that is done to create a perfectly working product meeting all the required benchmarks. The functions generally covered in these phases are Coding, Testing and Deployment. The teams involved are normally quite large and the work is quite predictable with extremely stringent timelines.

**The fact that we need to have a more detailed segregation of activities and stages, so as to relate to the SDLC in a more efficient manner, is the only reason why we’re breaking these two categories further down.

The aforementioned categories make good sense, but lack detailing, so we move a further division of the boundary lines.

The Engineering Stages are constituted by two smaller subdivisions, namely INCEPTION and ELABORATION. The Production stages on the other hand are constituted by two other smaller subdivisions, namely CONSTRUCTION and TRANSITION. We will be discussing these phases in complete detail at a later stage, but it is again important to note that the names of these phases are more than self-explanatory which makes it very clear that their functioning cannot be different to what their names sound like.

**Another important thing to recall here is that when the discussions over these stages were held in the class, a direct correlation between Boehm’s Spiral Model and these stages was drawn. This will be the case here as well, as the spiral model helps us put into perspective the exact reasoning behind the creation of these phases. Understanding an end to end implementation of a project via these stages and the spiral model is of utmost importance, which is where the case studies that we’ve discussed will come into the picture.

One major difference between the conventional life cycle phases and the phases discussed here is that in earlier models the phases were worked with in a sequential manner, but because in this model, iterations come into picture, everything is done in the each cycle and the project keeps developing on all fronts throughout the development cycle.

INCEPTION Phase: You need to understand the primary goals for all the sections, so as to get a gist of what the work done in these phases is all about. For the inception phase, the primary objective is to arrive at a basic idea of what the project would look like at completion. This encompasses all kinds of details regarding the functionality of the


project and all the stakeholders need to be satisfied at the end of it. Listing some of the objectives down:

o Establishing the scope and boundary conditions, including an operational concept and acceptance criteria. The client and the vendor’s management will take direct control of this.

o Coming up with the critical use caseso Demonstrating some kind of a sample or demo architecture against one of the

primary scenarios derived.o Cost and Schedule estimation. This again is completely handled by the IT vendor

management.o Risk Management. Risk management includes recognizing the risks and

acknowledging their presence. This phase does not include ways of mitigating those risks

The essential activities that are carried out in this phase are direct derivatives of the primary objectives that we’ve just witnessed. Some of them have been listed down below:

o Formulating the scope of the project: Primarily the assembling of the requirements and operational concept in an information repository. The repository is generally accessible by all the parties concerned, which ensures consistency between all the artifacts produced in this stage.

o Architecture Synthesis: The primary architecture of the product is arrived at, during this phase. The architecture includes the choosing of different technologies, chalking out the design of the product and getting a hang of the requirements of the environment. All of this information is base lined once so as to have it signed off from the client, so as to go ahead with the sample architecture (Candidate architecture).

o Planning and preparation of business cases. All alternatives regarding the staffing, resource allocation, infrastructure setup, cost/schedule profitability is determined. These initial estimates prove to be crucial as the terms and conditions are placed as per these requirements, and as the project progresses the team tries to stick to these estimations as long as it is even remotely possible.

Now once we have all of this ready and in place, the phase needs to be evaluated for completion. Only after the successful completion of this phase can the development move on the next one. The primary evaluation criteria are listed below:

o All the stakeholders concur on the scope definition and cost and schedule estimates?

o Requirements understood, on the basis of the validity of the critical use cases?o Credibility of the cost and schedule estimates, priorities, risks and development

processes?


o Is the architecture prototype (Candidate or sample architecture) comprehensive and does it set up the correct basis for successful completion of the project?

o Is the comparison between the resources and the planned expenditure realistic?

Once all of the above mentioned evaluation criteria are met, we move on to the next Life Cycle phase, which is the

ELABORATION PHASE: The elaboration phase, just as the name suggests, is all about elaborating the planning done in the previous phase. If you try to fit in the meaning of the word elaboration into the conventional SDLC, you’ll see that it fits best in the design phase. The primary work done in the Elaboration phase will be done on the designing front. It’s easy to realize the importance of the Elaboration phase, because the kind of outputs it holds prove to be the very basis of the decision whether time and effort can be put into the development. The project cannot be called off any later than the Elaboration phase.

The most important output of the elaboration phase is an executable Architecture Prototype, which at least fulfills all the critical case conditions. This prototype may or may not sustain itself through the future cycles, but to show that the project insight can be completed is of utmost importance.

Please find the primary objectives listed down:o Base lining of the architecture. It is done as rapidly as practically possible. This helps us

move forwards towards achieving that elusive critical case satisfying prototype which will ensure that the project sees the light of the day.

o The Vision document or simply the vision is base lined as well.o The Plan for the next phase, which includes designing and laying out the guidelines and

the processes, is created and base lined.o Demonstrating the feasibility of the architecture prototype with respect to cost and

time.

Just as the pattern in the previous phase, there are a lot of activities that are done in this phase as well, with most of them falling under the architecture and designing phase. Please find below the essential activities listed down:

o Elaborating the vision: Obvious as it sounds, the phase is all about it. What we are referring to here is the enhancement of your understanding about the requirements.

o Detailing and elaborating the process and infrastructureo Detailing and elaborating the architecture. Also the selection of the components. All the

options regarding the different components needed to setup the architecture required are considered and different evaluations are carried out. This helps estimate the infrastructure and architecture component cost more effectively.


Now that the activities and objectives have been discussed, the last component would be the evaluation criteria. Find them listed below:

o Stability of the vision?o Architecture Stable?o Does the architecture prototype show that the risk elements have been addressed and

resolved? *This becomes extremely important, as the sole purpose of having an executable architecture prototype is to ensure that all the major risks can be mitigated and all the critical cases can be implemented.

o The construction phase plan is designed well and is credible?o Are all stakeholders on board with the go ahead for the project to be executed as per

the plan coming out of the elaboration phase?o Comparison between planned resources expenditure and resources present at disposal

comparable?

Moving on from the elaboration phase, once all of the aforementioned evaluation criteria are met, we will have the moment of reckoning for the project, i.e. where the project or the software being developed actually start taking shape.

CONSTRUCTION PHASE: This is by far the most obviously named phase. All the components and features of the product are developed and integrated into one final unit. Once the development is concluded, rigorous testing of the final product is carried out making changes on the way as per the defects discovered. Depending on the size of the project, the development and the testing phases along with all the other activities are carried out in parallel. This increases the productivity manifolds and saves a lot of time, but adds on a lot of weight on the resource management and workflow synchronization front.

The product development and testing phase pulled into one means that the objectives are narrowed down. Find them listed here

o Focus remains minimizing development costs by optimum use of the resources and putting in as many reusable processes and modules in place as possible.

o Required quality to be achieved in the shortest time possibleo Achieving useful versions or releases throughout the development process

The essential activities which are listed down here are again, just like all the other phases, direct derivatives of the aforementioned objectives.

o Resource Management, control and process optimizationo Complete component development and testingo Assessment of the releases against the listed and base lined vision.


The essential activities are pretty straightforward here and do not need much detailing. The evaluation criteria too thus, is expected to be pretty simple, and it is indeed the case. Find the Primary Evaluation Criteria listed below:

o Is the base lined product from the current cycle, mature and evolved enough to be deployed into and used by the user community? (This is basically evaluating whether the final product of a cycle of development and testing is worthy of being called an official release or version)

o Is the base lined product from the current cycle, stable enough to be deployed into the user community?

o Are stakeholders onboard with the idea of moving on with the transition into the production environment?

o Comparison between planned and actual resource expenditures. Are they acceptable or not?

The construction phase gives us the development and testing outputs that we all love to see. Once the project is in green and the management along with all the stakeholders concerned, term the phase to be complete, we move on to the next phase:

TRANSITION PHASE: It makes logical sense, the name of the phase that is. Once the construction is completed and the go ahead of all the stakeholders is received, the product developed needs to be moved from the development or testing environment to the production environment. The UAT system can generally precede the actual implementation or deployment.

All projects generally have large deployment teams, specified for handling just this phase. If they don’t, the ratio of 1:5 defines the number of test resources/development resources in a makeshift deployment team.

Beta testing of the new system, along with the legacy system in operation if applicable, is an activity that will more often than not be included. Conversion of all operational databases as per the new system and the training of the concerned manpower are obvious activities that will be included in the phase. Arriving to an end product through multiple iterations and then delivering the perfect product is what makes the day for the IT vendor at the end of the day.

Let’s have a look at the primary objectives:o Achieving user self-supportability (Making the client or the end user competent enough

by the time the transition phase completes, that it is able to operate and handle the complete software product on its own with minimal interference required from the vendor end)

o Deployment base lines are in concurrence with the vision doco Final product base lines need to be achieved in the most practical and quick manner

This leads us to the Essential Activities:


o Consistently deploying the versions available. o Deployment Specific Engineering (This includes the various tricks of the trade, so as to

make our product more marketable and extremely more practical)o Assessments of the base lined deployments (Releases) against the mentioned criteria

and the vision document

The activities too did not need much, on the explaining part. So we just have the final residual of the Evaluation criteria to deal with, and they have been mentioned and listed below:

o User satisfied? (o Are the actual and estimated resource expenditures comparable and acceptable?

The phases thus are very simple and easy to understand. They can be very easily related to the conventional S/W models and SDLC, which makes them both practical and effective.


ARTIFACTS

An artifact is a single entity that stores information related to a specific function in a given project. The language of the artifact is decided through the kind of work that the artifact does. It may or may not be a document, although all documents created during the completion of a project are artifacts. These artifacts help store and manage information in a very effective manner and prove to be of utmost importance where important sign offs from the client need to be achieved. The artifacts that we’re going to discuss are direct derivatives of the ones being produced in the industry on a daily basis. There is also a simple segregation pattern that we’re going to follow, so as to make the study simpler.

The artifacts encountered in the process of project development are broadly categorized into two types, called artifact sets, Management set and Engineering Set.

Let’s discuss Management Set in details first.

Management Set: The management set of artifacts, quite obviously will be dealing with the work done at the management end during the course of a software development. The Management is generally involved in the Planning and process execution part. So the artifacts present in this set are mostly related to planning and the setting up of processes. The artifacts use ad hoc notations, text, graphical notations, UMLs or whatever means required, to get the message through. This big variety of languages used, make the management artifacts quite varied and since they are created at such a juncture, it becomes imperative to make all the information crystal clear. Some of the specific artifact examples of the management set that we’re going to be discussing in the next few pages are Work Breakdown Structure, Business Case, Release Specification doc, Software Development Plan, Software Change Order Databases and more. There is a small pattern as to how the management set artifacts are evaluated and assessed for completion and validity, which is described below

o Stakeholder Reviews. The single most important way of getting an artifact signed off, that is by getting a detailed review of the primary stakeholder

o Analysis between the different versions of the artifact. This helps you understand the kind of growth the artifact has gone through and that all the problematic elements have been dealt with.

o The accuracy of the artifacts, the vision and business case artifacts in particular. Engineering Set: Just like the name suggests, the artifacts developed during the actual course of

the project build i.e. during the engineering and production phases of the life cycle, are grouped in this category. It is further subdivided in a number of categories, according to the phases that the artifacts developed in this group are created in. Let’s have a look at all the subdivisions

o Requirements Set: An extremely crucial set with a lot of possible artifacts generated in the requirements gathering phase directly coming in. One of the primary artifacts of this


phase, is the vision document, which is nothing but the textual representation of what‘s been agreed upon in the contract. The base lined version of this document may or may not be used for a lot of other compliance and assessment tasks. The other artifacts generated are quite obvious, such as the SRS, the critical cases document and other high level requirement gathering and understanding related document, which makes the requirements clearer and sorted by the end of the entire phase. The way these artifacts are evaluated and assessed are mentioned below

Comparison with the release specifications of the management set is constantly done, to check for consistency.

The Vision document and the requirement models are also constantly compared Mapping the Requirement artifacts to the different artifacts generated in the

coming Sets. This is to ensure that all the artifacts generated in the life cycle are in complete sync and are totally consistent.

Comparisons between the different versions of an artifact. Subjective reviews by the required authorities

o Design Set: The language of choice in the design set, is generally UML notations. The various design documents, along with the architecture documents and the framework of the entire project, can all be represented in the most effective manner using UML. The design documents like HLD, DLD, Architecture Description Document and other detailing artifacts. The various assessment criteria and methodologies are as follows:

Analyzing the internal quality and consistency of the design models set up Checking for consistency with the Requirements Translation into the future sets, to check the validity of the artifacts generated Analyzing the changes between the current and previous versions of the

artifacts Constant subjective review of the artifacts by the required authority

o Implementation Set: The primary artifact of this set is the Source code for the product. Since the set comprises of artifacts generated mainly in the coding and testing phase, it is understandable that the artifacts here will be quite straightforward and specific. Apart from the source code, any individual unit or component which will assist the testing part of the project will also be considered an artifact. Apart from that all the documents created during the coding or testing will be immediate base lined artifacts for this phase. Since the concentration of construction activities in this phase is so high, the number of artifacts generated here is much higher than any of the other sets. Examples of the artifacts are: Source Code, Test Plan, Test Data Document, input test data files, Test result files, Test Case Documents and many more. Please find the different assessment criteria and methodologies listed below:

Checking the consistency with the design models Translation into the next set, so as to confirm the validity and the utility of the

artifacts Assessment of Source code against an extremely relevant and functional criteria Execution of test cases


Comparisons between the current and the previous versions of the artifacts Constant and subjective reviews of the artifacts by the relevant authorities

o Deployment Set: The last of the artifact set categorization, it obviously deals with the transition of the finished product from the vendor environment to the client environment The artifacts considered here are the executable code, the release schedule, the proper base lined release description, user manuals, installation scripts and many more. Please find the evaluation criteria mentioned below:

Testing against the usage scenarios and quality attributes defined in the requirement artifact set.

Mapping the components of the implementation set to the physical resources of the deployment system. This essentially means the transitioning of the software from the test environment to the actual moving to the physical environment on the client side

Testing against the defined usage scenarios in the usage manual Analysis between the current and the previous versions of the deployment set Subjective and constant review of all the artifacts by the required authorities

The idea behind the creation of these different artifact sets was not to create a strict guideline, but to be able to optimize the presentation of the different processes in place. The subsequent topics of this chapter will not be discussed in detail, and need to be referred through the Reference book, in case you are looking for details. A brief outline is given below:

Implementation set vs Deployment Set: Walker Royce has tried to separately distinguish between the two artifact sets, as he believes that even though the artifacts generated in these sets are highly related, there are a lot of activities in these phases that are non-dependent. To coin an answer to this question you could directly use your knowledge about the different sets or dive into the specific details mentioned by Royce in the book.

Artifact Evolution over the Life Cycle: Figure 6-3 on page number 92 is what defines this section. This is a rough distribution of the concentration of the quantities of artifacts generated in the different phases. The figure will give you a complete picture as to what the two page text written in the book is all about

Test artifacts: A separate section dealing with the different test artifacts created over the life cycle of a project. This has the same artifact set segregation discussed above. Some examples for the artifacts generated have been given below:

o Management Set: Testing Plan, Software Change Order databaseso Requirements set: Critical Use Cases, business cases and the complete requirement set

itselfo Design Set: A design model for setting up the testing plan for non-deliverable

components is set up. The DLD and the Detailed Testing Plan can also be considered to be a part of the Design set.


o Implementation Set: Test Cases (ST), Test Cases (UT), Test Data, Test results, test completion reports and Test Analysis.

o Deployment Set: Executable versions of the test components, test drivers and data files. Examples of Management Artifacts: There are a number of artifacts which have been listed

down. All of these have been discussed in the classroom sessions, and most of them are self-explanatory, but if you are still looking for details, please glance over the respective section in the book which is Pg. No. 96-102. Figure 6-8 on Pg. 102 is nothing but a rough sequence given to understand the emergence of different artifacts in the life cycle of a product

Examples of Engineering Artifacts: Same instructions as for the previous section. Pg No 103-104.

Pragmatic Artifacts: Royce has discussed some characteristics of artifacts that are considered to be practically or pragmatically sound. This piece of text is quite conversational and straightforward. A single read should suffice. Page 106-107

This wraps up our syllabus for the mid-semesters. Again, you guys need to be clear on one front which is the logical answering freedom that you behold in SPM. All answers here are interrelated and if you try to link one thing to the other and find a pattern, chances are that the pattern will be correct. Please refer to the reference book in case of any ambiguity and feel free to reach out to me in case you need any clarifications. Happy Prep Days!!