Unit –I

Software Development process:A software development process is concerned primarily with the production aspect of software development, as opposed to the technical aspect, such as software tools. These processes exist primarily for supporting the management of software development, and are generally skewed toward addressing business concerns. Many software development processes can be run in a similar way to general project management processes. Examples are:

Risk management is the process of measuring or assessing risk and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Risk management in software project management begins with the business case for starting the project, which includes a cost-benefit analysis as well as a list of fallback options for project failure, called a contingency plan.

o A subset of risk management that is gaining more and more attention is "Opportunity Management", which means the same thing, except that the potential risk outcome will have a positive, rather than a negative impact.

Requirements management is the process of identifying, eliciting, documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. New or altered computer system[1] Requirements management, which includes Requirements analysis, is an important part of the software engineering process; whereby business analysts or software developers identify the needs or requirements of a client; having identified these requirements they are then in a position to design a solution.

Change management is the process of identifying, documenting, analyzing, prioritizing and agreeing on changes to scope (project management) and then controlling changes and communicating to relevant stakeholders. Change impact analysis of new or altered scope, which includes Requirements analysis at the change level, is an important part of the software engineering process; whereby business analysts or software developers identify the altered needs or requirements of a client; having identified these requirements they are then in a position to re-design or modify a solution. Theoretically, each change can impact the timeline and budget of a software project, and therefore by definition must include risk-benefit analysis before approval.

Software configuration management is the process of identifying, and documenting the scope itself, which is the software product underway, including all sub-products and changes and enabling communication of these to relevant stakeholders. In general, the processes employed include version control, naming convention (programming), and software archival agreements.

Release management is the process of identifying, documenting, prioritizing and agreeing on releases of software and then controlling the release schedule and communicating to relevant stakeholders. Most software projects have access to three software environments to which software can be released; Development, Test, and Production. In very large projects, where distributed teams need to integrate their work before release to users, there will often be more environments for testing, called unit testing, system testing, or integration testing, before release to User acceptance testing (UAT).

o A subset of release management that is gaining more and more attention is Data Management, as obviously the users can only test based on data that they know, and "real" data is only in the software environment called "production". In order to test their work, programmers must therefore also often create "dummy data" or "data stubs". Traditionally, older versions of a production system were once used for this purpose, but as companies rely more and more on outside contributors for software development, company data may not be released to development teams. In complex environments, datasets may be created that are then migrated across test environments according to a test release schedule, much like the overall software release schedule.

Project planning, monitoring and control

The purpose of project planning is to identify the scope of the project, estimate the work involved, and create a project schedule. Project planning begins with requirements that define the software to be developed. The project plan is then developed to describe the tasks that will lead to completion.

The purpose of project monitoring and control is to keep the team and management up to date on the project's progress. If the project deviates from the plan, then the project manager can take action to correct the problem. Project monitoring and control involves status meetings to gather status from the team. When changes need to be made, change control is used to keep the products up to date.

Notes on project management issues

Topic

Principles of project planning

Project initiation

Project lifecycles & planning

Identifying tasks & estimating

Quality issues

Anticipating problems & motivation

Financial issues

Applying principles

Unit-II

Software Economics includes many different disciplines:

Many of in the field of software development limit their understanding of the field to only the technical aspects.

Software Economics examines the entire idea of software development and it includes many different disciplines.

Psychology - focuses on the study of behavior and the reward/punishment model. "What get's rewarded gets done."

Social Psychology - focuses on how people behave in an organization, quality of work life, and peer pressures.

Organizational Behavior - is the process of analyzing the structure of an organization to understand those structural issues impacting organizational productivity and quality.

Economics - the study of prices, costs, and scarcity.

Statistics - deals with quantitative and qualitative techniques for the collection of data, how data is analyzed, and how results are presented.

Cost estimation models:

Cost estimation models are mathematical algorithms or parametric equations used to estimate the costs of a product or project. The results of the models are typically necessary to obtain approval to proceed, and are factored into business plans, budgets, and other financial planning and tracking mechanisms.

These algorithms were originally performed manually but now are almost universally computerized. They may be standardized (available in published texts or purchased commercially) or proprietary, depending on the type of business, product, or project in question. Simple models may use standard spreadsheet products.

Models typically function through the input of parameters that describe the attributes of the product or project in question, and possibly physical resource requirements. The model then provides as output various resources requirements in cost and time.

Cost modeling practitioners often have the titles of cost estimators, cost engineers, or parametric analysts.

Ada COCOMO:

COCOMO has continued to evolve and improve since its introduction. Costar supports the traditional COCOMO model, and the most recent models.

The document TRW IOC Ada COCOMO: Definition and Refinements (Barry Boehm & Walker Royce, 1987, 1988) defines the "Ada COCOMO" model.

Each model consists of cost drivers, equations; phase distribution tables, etc., and is stored in a file as a Costar model (with extension "mdl"). You can modify any of the Costar models to match your development environment.  Costar 7.0 has 13 built-in models.

The two cost drivers, SECU (Classified Security Application) and RUSE (Required Reusability) have been added to the Ada COCOMO model.

The model named "ADA_87" assumes that the Ada programming language is being used. Use of Ada makes it easier to develop highly reliable systems and to manage complex applications, so the cost drivers RELY and CPLX have new definitions.

The APM_88 model is based upon a different "process model" called the Ada Process Model. Among the assumptions are:

You use Ada to produce compiler checked package specifications by the Product Design Review (PDR) Small design teams are used More effort is spent in requirements analysis and design Less effort is spent in coding, integration, and testing

The APM_88 model incorporates changes to the equations, several cost drivers, and a variety of other tables.

This table summarized the different COCOMO models you can use in Costar. Remember that you can use our tools to create your own versions of the COCOMO models and tables, calibrated to your development environment.

The Capability Maturity Model (CMM) is a service mark registered with the U.S. Patent and Trademark Office by Carnegie Mellon University (CMU) and refers to a development model that was created after study of data collected from organizations that contracted with the U.S. Department of Defense, who funded the research. This became the foundation from which CMU created the Software Engineering Institute (SEI). Like any model, it is an abstraction of an existing system.

When it is applied to an existing organization's software development processes, it allows an effective approach toward improving them. Eventually it became clear that the model could be applied to other processes. This gave rise to a more general concept that is applied to business.

UNIT-III

An artifact is one of many kinds of tangible by-product produced during the development of software. Some artifacts (e.g., use cases, class diagrams, and other UML models, requirements and design documents) help describe the function, architecture, and design of software. Other artifacts are concerned with the process of development itself—such as project plans, business cases, and risk assessments.

The term artifact in connection with software development is largely associated with specific development methods or processes e.g., Unified Process. This usage of the term may have originated with those methods.

Build tools often refer to source code compiled for testing as an artifact, because the executable is necessary to carrying out the testing plan. Without the executable to test, the testing plan artifact is limited to non-execution based testing. In non-execution based testing, the artifacts are the walkthroughs, inspections and correctness proofs. On the other hand, execution based testing requires at minimum two artifacts: a test suite and the executable. An artifact occasionally may be used to refer to the released code (in the case of a code library) or released executable (in the case of a program) produced but the more common usage is in referring to the byproducts of software development rather than the product itself. Open source code libraries often contain a testing harness to allow contributors to ensure their changes do not cause regression bugs in the code library.

Much of what are considered artifacts is software documentation.

In end-user development an artifact is either an application or a complex data object that is created by an end-user without the need to know a general programming language. Artifacts describe automated behavior or control sequences, such as database requests or grammar rules, or user-generated content.

Artifacts vary in their maintainability. Maintainability is primarily effected by the role the artifact fulfills. The role can be either practical or symbolic. In the earliest stages of software development, artifacts may be created by the design team to serve a symbolic role to show the project sponsor how serious the contractor is about meeting the project's needs. Symbolic artifacts often convey information poorly, but are impressive-looking. Symbolic artifacts are sometimes referred to in the information architecture industry as Illuminated Scrolls, because the decorations do nothing to enhance understanding. Generally speaking, Illuminated Scrolls are also considered unmaintainable due to the diligence it requires to preserve the symbolic quality. For this reason, once Illuminated Scrolls are shown to the project sponsor and approved, they are replaced by artifacts which serve a practical role. Practical artifacts usually need to be maintained throughout the project lifecycle, and, as such, are generally highly maintainable.

Artifacts are significant from a project management perspective as deliverables. The deliverables of a software project are likely to be the same as its artifacts with the addition of the software itself.

The sense of artifacts as byproducts is similar to the use of the term artifact in science to refer to something that arises from the process in hand rather than the issue itself, i.e., a result of interest that stems from the means rather than the end.

Life cycle phases:

Our service program is designed for the long haul. We support our customers’ success with service solutions that cover the entire life cycle of plants and projects. Solutions that consider tomorrow’s needs today. Solutions that grow with you. We have grouped our services according to a system we call the Service Navigator. Infraserv will offer you just the right services for your current phase of development to support your business competently, efficiently and reliably.

Life-cycle phase 1 – The idea

In the idea phase, we will identify your needs and processes and map out a conceptual design with you that cover all the details. This design forms the basis for your success. Trust our experience – we know what future questions require an answer today.

Life-cycle phase 2 – The planBased on the detailed design concept, we will prepare a comprehensive, detailed plan – poising your project for success. Experts from different fields draw on their expertise to make your ideas and wish a reality. Whatever your plans are: We will make them happen.

Life-cycle phase 3 – The operations

During the operations phase, we will provide exactly the services you need. There are some things that you just want to work. Period. Let us handle these support processes for you so your business, your production can run without a hitch – reliably and efficiently. And in the end, you can focus on what counts: your business.

Life-cycle phase 4 – The enhancement

Your business keeps evolving; your company is facing new challenges. During the enhancement or rehabilitation phase, we will make sure that you are ready to face the challenges of tomorrow and are equipped for the future. Our service programs grow with you, along with your facilities and processes.

IV UNIT

Model-driven architecture (MDA) is a software design approach for the development of software systems. It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model-driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.

The architecture of a design is the set of rules that ensure consistency across all of its parts.  By setting out how a range of design decisions should be made across a development, it reduces the effort needed in the design of each part; and at the same time makes the design more flexible and more usable by ensuring uniformity in appropriate aspects.  Architecture isn't just the design of the large pieces. While the distinctions are somewhat arbitrary, we take design to mean creating a larger part from some smaller ones -- each of which could itself be specified and given to separate people to design. Whether the pieces we're talking about are grand distributed systems composed from substantial subsystems, or whether they are little subroutines made up from a few program statements, design means working out how the smaller parts make up the bigger one.

If each piece in a big project were given to someone to design in complete isolation, the resulting complete system would look a bit incoherent. The architecture of a system is the set of guidelines followed by all the designers, making the parts coherent.

By analogy, think of the development of a large building. Each room is necessarily somewhat different in its exact shape and function, and each is designed by a separate designer. But (in a sensible building) there is a coherence of style that guides the decisions that each designer might otherwise make arbitrarily: for example, the height of the rooms, the choice of window frame. These rules make it easier to fit the parts together; they save us from having to procure hundreds of different windows, and also make life easier for the occupants.

In families of products, the architecture is crucial in ensuring different family members can readily be formed by composing the components in different configurations.

A workflow is a depiction of a sequence of operations, declared as work of a person, a group of persons, an organization of staff, or one or more simple or complex mechanisms.

The flow being described often refers to a document that is being transferred from one step to another. Workflow is divided according to level of complexity, flexibility, purpose, and structure. Most industry

analysts maintain that there are three types: Production Workflow Administrative Workflow Ad Hoc Workflow

The Workflow Lifecycle (WFLC) defines both the way in which the different activities involved in the development and use of WF.

It comprises three main processes: Construction and stabilization Debugging Business process reengineering

Iteration Workflow Iteration workflows provide a time based view of the process. One iteration workflow describes a typical workflow within an iteration of a given phase of a software project. Iteration workflows differ from discipline workflows in that the work, described as workflow details, cover cross-discipline concerns. It's a true workflow from the perspective of iteration in the project.

In UML terms, a workflow can be expressed as a sequence diagram, a collaboration diagram, or an activity diagram. We use a form of activity diagrams in the RUP. For each phase, an activity diagram is presented. This diagram shows the workflow, expressed in terms of workflow details and their major deliverables. The main roles participating in the workflow details are described as swim lanes in the activity diagram.

Iteration workflows are effective means to describe the lifecycle model of a software development process.

UNIT - V

CHECKPOINTS:

Check Points of the Process:Three Sequences of Project Check Points are used to synchronize Stakeholders expectation throughout the Lifecycle:1: Major Milestone2: Minor Milestone3: Status assessments

Milestone:A Milestone is a significant event in a project, usually associated with the major project. Milestone have zero duration, they mark only at a time when something important has been completed. They can be defined for the end of one or more activities.

Milestone-Based ApproachThis process model consists of four high-level milestones as represented in the following diagram.

Process milestonesThe milestones are depicted as points on a spiral — rather than a straight line — to emphasize that the process is cyclical and iterative rather than linear. Milestones are not freeze points. Rather, they are "baseline" points at which the deliverables described by the milestone are placed under change control.This facilitates flexibility and successive refinement briefly; the four major milestones are described in the following list.

1. Vision/Scope Approved milestone once a new application gains interest and approval, a project team is assembled to define the product. A vision statement establishes scope and provides direction. The Vision/Scope Approved milestone is an opportunity for both end users and the development team to agree upon the project scope and vision.

2. Functional Specification Approved milestoneThe next visible milestone is availability of a functional specification baseline. This specification provides enough detail about the application. At this milestone, users and team members agree on what is to be delivered and establish priorities and expectations.

3. Code Complete milestoneThe Code Complete milestone is an opportunity for users and team members to make a final assessment of the release and to verify that rollout and support plans and procedures are in place.

4. Release of Product milestoneAfter the code has baselined, beta programs, testing, and quality assurance activities are performed concurrently with further code refinement, driving the system to the Release milestone.

The Release milestone is the point when the application (or "product") is formally turned over from the project team to the operations and support groups.

These four milestones are major progress points that embody all major development concepts.Three types of joint Management reviews are conducted throughout the Process:

Major Milestones:These events are held at the end of each Development phase. They provide visibility to system wide issue, synchronize the issue.

Minor Milestone:These are the Iteration focused events. They are conducted to review the contents of iteration in detail.

Status Assessments:These are those events which are used to provide Management. These taken considerations of the progress being made.

Usually at the start of a new project, a project manager has to forget the sad points of the previous projects and also to get to ground from the unusual achievements too. At this juncture a project manager is supposed to start afresh with new zeal, a new team or new members in the team, a new working, a new strategy and a new requirement. At the start of any new project and during the project, if the project manager keep track of following 15 checkpoints, he is safeguarding his project towards timely and successful completion of his project.

The 15 checkpoints can be listed as below (not in hierarchical manner though):

1. It is important to create and follow a methodology for your software project management.

2. Let your project management not turn into a sad story.

3. Out of a project methodology and adhering to it, adherence is more critical, whatever methodology you

design for your projects management.

4. Different software projects may not necessarily fall into the same methodology. So depending on your project

type you need to define a separate project management methodology. For instance there might be a difference

between your in-house, domestic and offshore projects.

5. An unfit methodology or wrong way of managing your project may cause a retardation in the progress of

your project thereby causing a frustration in project stakeholders.

6. The maturity in the way a project is managed decides the success or failure of project.

7. Project management methodology may also depend on the project size also.

8. Don’t let your methodology become stale by not observing, evaluating and redesigning it.

9. Various soft spots or loopholes in your project methodology may cause a number of wrong results in your

project thereby deviating you and your teams from the desired progress or flow of the project.

10. A real transformation is required from time to time to keep your project and methodology you are adhering

to – to keep the progress on track.

11. You must be very clear all the time to understand and adopt the real ingredients to keep your project end in

time successfully.

12. The project manager has to become maverick sometimes to pinpoint the flaws in project and overcoming

them.

13. The project manager has to have certain set of skills to keep his project alive so as to accelerate the progress.

14. The project manager has to have handy checkpoints at the start of a project.

15. The project manager has to interact, interject or do both during the project.

16. The large sized projects have more chances of failures if not managed properly.

UNIT- VI:

Project Organizations and Responsibilities

Introduction: Business concerns are established with the objective of making profits. They can be established either by one person or by a group of persons in the private sector by the government or other public bodies in the public sector. A business started by only one person is called sole proprietorship. The business started by a group of persons can be either a Joint Hindu Family or Partnership or Joint Stock Company or a Co-operative form of organization.

An LOB (line-of-business) application is one of the set of critical computer applications that are vital to running an enterprise, such as accounting, supply chain management, and resource planning applications. LOB applications are usually large programs that contain a number of integrated capabilities and tie into databases and database management systems.

Increasingly, LOB applications are being connected with network applications with user interfaces on the Web and with personal applications such as e-mail and address books.

Thus there are various forms of business organization

1. Sole Proprietorship 2. Joint Hindu Family Firm 3. Partnership Firm4. Joint Stock Company5. Co-operative Society

Forms of business organization are legal forms in which a business enterprise may be organized and operated.

These forms of organization refer to such aspects as ownership, risk bearing, control and distribution of profit. Any one of the above mentioned forms may be adopted for establishing a business, but usually one form is more suitable than other for a particular enterprise. The choice will depend on various factors like the nature of business, the objective, the capital required, the scale of operations, state control, legal requirements and so on.

Features: The important features of sole proprietorship are:

1. The business is owned and controlled by only one person.2. The risk is borne by a single person and hence he derives the total benefit.3. The liability of the owner of the business is unlimited. It means that his personal assets are also liable to

be attached for the payment of the liabilities of the business.4. The business firm has no separate legal entity apart from that of the proprietor, and so the business lacks

perpetuity.5. To set up sole proprietorship, no legal formalities are necessary, but there may be legal restrictions on

the setting up of particular type of business. 6. The proprietor has complete freedom of action and he himself takes decisions relating to his firm.7. The proprietor may take the help of members of his Family in running the business.

Advantages

1. Ease of formation: As no legal formalities are required to be observed.2. Motivation: As all profits belong to the owner, he will take personal interest in the business.3. Freedom of Action: There is none to interfere with his authority. This freedom promotes initiative and

self-reliance. 4. Quick Decision: No need for consultation or discussion with anybody.5. Flexibility: Can adapt to changing needs with comparative ease. 6. Personal Touch: comes into close contact with customers as he himself manages the business. This helps

him to earn goodwill. 7. Business Secrecy: Maintaining business secrets is very important in today’s competitive world.8. Social Utility: Encourages independent living and prevents concentration of economic power.

Disadvantages

1. Limited resources:

One man’s ability to gather capital will always be limited.

2. Limited Managerial Ability3. Unlimited Liability:

Will be discouraged to expand his business even when there are good prospects for earning more than what he has been doing for fear of losing his personal property.

4. Lack of Continuity:

Uncertain future is another handicap of this type of business. If the sole proprietor dies, his business may come to an end.

5. No Economies of Large Scale:

As the scale of operations is small, the owner cannot secure the economies and large scale buying and selling. This may raise the cost of production.

UNIT- VII:

Tailoring the Process Process Discriminates:

In tailoring the management process to a specific domain or project, there are two dimensions of discriminating factors: 1. Technical Complexity 2. Managerial Complexity

Different types of systems, and their projects, can be classified in terms of the technical complexity of the system and the managerial complexity. The following figure illustrates one concept of how different systems can be classified. For example, a typical small business spreadsheet application is often of low technical complexity and is easy to manage. The other extreme is a typical weapon system project, which is often both technically complex, and complex to manage. Usually increasing system size, project duration or business context also increases the managerial complexity. Increasing the novelty, in either the problem domain or the solution space, increases the technical complexity. There is an interaction between managerial and technical complexity as well-many large projects are also technically complex. This results in: Increased managerial complexity that leads to more ceremony, including more formal reviews and milestones, and more artifacts.

Increased technical complexity that leads to the introduction of specific techniques, roles and tools, and, therefore, more activities.

The Current Development Process In most cases, you won't replace the software-development process currently in practice in the organization because, in most cases, you'll implement the new development process step-by-step, focusing on the more critical and important areas first. Some of the current software-development process may even continue to exist for some time, perhaps forever.

Problems and Root Causes An important aspect of understanding a software-development organization is to understand the problems in the existing software-development process. This influences those areas of the process you will concentrate on in the beginning of the process implementation. It's important to note that, if there is no established way of working in the organization, it may be pointless to find problems. Instead, you may need to identify the root causes of the problems. To eliminate the problems, you will tackle the root causes by improving their process, introducing tools to automate the process, and training people. 

Examples of common problemsThe following are examples of some common problems:

[1] Inability to manage scope-the organization routinely tries to do more than they actually do in the end. [2] Inability to capture requirements-they have difficulty specifying requirements. [3] Inability to manage changing requirements. [4] Inability to manage requirements-requirements do not make it to the final product. [5] Inability to estimate-they are routinely too optimistic about their ability to deliver on schedule. Design deficiency-they are good at meeting requirements, yet poor at designing systems. What kinds of

design problems do they have? Are the systems difficult to maintain and enhance? Do they have performance problems, usability problems, capacity problems, and so on?

Inability to produce quality products-the product has too many defects which may be due to lack of testing, but usually is also related to an inability to capture and manage requirements, as well as design deficiency.

Unacceptable software performance. Low usability. Colliding developers-there is a lack of control over ownership and configuration management, so that

developers make conflicting changes and work is lost. Late discovery of problems.  Trouble going from use cases to design.

Examples of root causesA problem is often a symptom that something is wrong. You need to identify the root causes of the problems. The following are examples of some common root causes:  

[1] Insufficient requirements management [2] Ambiguous and imprecise communications [3] Brittle architectures [4] Overwhelming complexity [5] Undetected inconsistencies among requirements, designs, and implementations [6] Insufficient testing [7] Subjective project status assessment [8] Delayed risk reduction due to waterfall development [9] Uncontrolled change propagation [10] Insufficient automation [11] No systematic way to build user interfaces [12] No way to go from use cases to a design

Process Tailoring and the Software Capability Maturity Model:The Software Capability Maturity Model (SW-CMM) is serving as the foundation for a major portion of the process improvement being undertaken in the software industry. It is composed of two volumes: the Capability Maturity Model for Software and the Key Practices of the Capability Maturity Model. The key practices of the SW-CMM are expressed in terms that reflect normal practices of organizations that work on large, government contracts. There is, however, a significant population of software-producing and acquiring organizations, operating in different environments, for which the key practices require significant interpretation and/or tailoring, prior to application. This report presents a tailoring framework that identifies process artifacts, tailoring processes, and their relationships to project artifacts, and explores the nature of various kinds of tailoring used in the definition and development of software process descriptions. Techniques appropriate to each type of tailoring are then discussed. The general approach utilizes and builds upon the Software Process Framework, whose purpose is to provide guidance for designing, analyzing, and reviewing software processes for consistency with the SW-CMM.

UNIT-VIII

The MODERN conference assuring the quality of internationalization is the third in a series of five conferences organized by the MODERN European platform in higher education modernization. It will take place in Amsterdam on 7th May 2010.

As internationalization grows in importance in higher education and takes on a more mainstream role, there is a growing expectation for universities to be able to define the added value of the international dimension and measure the impact of internationalization on the institutional mission. Quality remains a controversial concept with a range of definitions and purposes – whether it is equated with excellence, fitness for purpose, value for money or the ability to transform. The challenge lies in balancing the need for trustworthy quality control that creates a “bottom line” in terms of accountability along with the need for a creative assessment structure that encourages initiative and stimulates institutional learning and improvement. Quality assurance in internationalization should be able to provide reliable information on institutional performance while taking into account the diversity of institutional missions and profiles.

For further details on the conference and the programme, please click here for the pdf document or visit the MODERNwebsite.

MODERN is a three-year EU-funded structural network project in the EU Lifelong Learning Programme, developed under the leadership of ESMU, in a consortium with 9 core partners, 28 associate partner European associations and academic providers of higher education management (HEM) training programmes. For further information on the MODERN platform and the online registration for the conference, please consult the MODERN website .