Abstract:
In software industry, the major problem is meeting the clients requirements with specific to a software project development is the deliverables that should be promised to the client. The client standardizes himself to a contract and fixes a specific time onto the systems, when the project has to be delivered. Once the software development contract is signed, the actual task on scheduling the manpower and machine requirements arises. In scheduling the manpower and machine requirements arise. In a software development process, if the manpower is not organized properly then it can cause a great lot of have in reaching the targets. The major goal of any software development firm is to meet the targets as fast as possible with the least manpower, to get targeted profits. The other area where the software developments firm are interested are with respect to the management of library with specific to the previous project development processes. The application training the bugs and their associated tescases that were developed previously also plays a vital role. The software project management solutions, is an application that kinds itself with the overall standards of managing a project at all levels of its development processes. The application is projected towards the maintenance of data, that is utmost necessary to know the state and status of a project that is undergoing through the process of development. The major intension its to maintain the history of all the components that have been developed for a specific projects along with the associated information about the software engineer who has been involved in the process of development of that component. This type of standard always helps the industry not only in managing the Human Resources properly but also help to keep down the maintenance upon the system. The history of information also helps in keeping the standards of bug tracking and bug management much easier, flexible and faster.
The project has been planned to be having the view of distributed architecture, with centralized storage of the database. The application for the storage of the data has been planned. Using the constructs of MS-SQLServer2000 and all the user interfaces have been designed using the ASP.Net technologies. The database connectivity is planned using the

presented by:
Mohd Zeeshan Ali

---

[attachment=9331]
Abstract
Under the topic SOFTWARE PROJECT MANAGEMENT ,we discuss how the project and product processes fit together to define a unique project instance. The basic things meant for a project management are why, what , how, do it, and did it .which in turn relates to initiating, planning, executing, controlling and closing , regardless of the nature of the project.
There are mainly four main things to be kept in mind about software project management, they are four p’s people, product, process and project.
Key concepts to be observed here are Agile teams, co-ordination, critical practices, software scope, software team, stake holders, team leaders.
The following are the questions raised while preparing a software project management
How can software metrics be use to manage projects ?
How do we estimate effort, cost and project duration ?
Techniques to be used to formally assess the risks ?
How does a software project manager select tasks ?
How is a project schedule created ?
What is quality management
Why are formal technical reviews so important ?
How changes are to be made to the software after delivery to the customer ?
Now we shall see in brief the answers to above questions and the requirements to define the goal and scope of a unique software project management.
INTRODUCTION
SOFTWARE PROJECT MANAGEMENT
Is concerned with activities
software is delivered on time and on schedule
Meets the requirements of the organisations that develop and procure the software.
KEY ELEMENTS
Project Management
Estimation
Project Scheduling
Risk Management
Quality Management
Change Management
PROJECT MANAGEMENT
The People
people must be organized into effective teams such as PM-CMM.
The Product
Product objectives and scope are defined here.
The Process
Process provides the framework from which a comprehensive plan is designed.
The Project
Project is used to manage complexity.
ESTIMATION
The software project planner must estimate these basic things before a project begins,
Scope of the project and feasibility.
Analyze risks.
Define required resources.
Estimate cost and effort.
Develop a project schedule.
PROJECT SCHEDULING
Software project scheduling is an activity that shows the total effort of individual activities done inside a planned project.Basic principles forProduct scheduling
Compartmentalization
Breaking the project into manageable actions, activities and tasks.
Interdependency
Interdependency of each compartmentalized activity , action , or task must be determined.
Time allocation
Each task must be allocated some number of work units.
Effort Validation
The number of people on the software team for a project must be defined.
Defined Responsibilities
Every task that is scheduled should be assigned to a specific team member.
Defined Outcomes
Every task that is scheduled should have a defined outcome.
Defined Milestones
Every task or a group of tasks should be associated with a project milestone
RISK MANAGEMENT
The Risk Management is to assist a project team in defining risks, assessing their impact and probability, and tracking risks through a software project.
Risk Identification
It is a systematic attempt to specify threats to the project plan
Risk Estimation
Establish a scale that reflects the perceived likelihood of a Risk.
Delineate the consequences of the Risk.
Estimate the impact of the risk on the project and the product.
Note the overall accuracy of the risk projection.
Risk Mitigation, Monitoring, And Management
Risk avoidance.
Risk monitoring.
Risk management and contingency planning.
QUALITY MANAGEMENT (SQA)
Software quality management is an umbrella activity that is applied at each step in the software process.
Consists the following steps:
SQA process
Specific quality assurance and quality control tasks
Effective software engineering practice
Control of all software work products
CHANGE MANAGEMENT(SCM)
The main objective here is to manage changes in effective way of software project.
SCM Activities
Identify and Control Change.
Audits and Reports modifications.
conclusion
Finally a project management activity encompasses the below things.
Measurement and metrics
Estimation and scheduling
Risk analysis, tracking and control
All these comprises to form a software project management

There are mainly four main things to be kept in mind about software project management, they are four p’s people, product, process and project. Key concepts to be observed here are Agile teams, co-ordination, critical practices, software scope, software team, stake holders, team leaders. It is really very important.

---

These are really very important in this. KEY ELEMENTS Project Management Estimation Project scheduling Risk Management. It is really very important to study more about it because it is very necessary for it.

[attachment=13650]
Applied Software Project Management
Software Testing
Quality
Quality means “conformance to requirements”
The best testers can only catch defects that are contrary to specification.
Testing does not make the software perfect.
If an organization does not have good requirements engineering practices then it will be very hard to deliver software that fills the users’ needs, because the product team does not really know what those needs are.
Test Plans
The goal of test planning is to establish the list of tasks which, if performed, will identify all of the requirements that have not been met in the software. The main work product is the test plan.
The test plan documents the overall approach to the test. In many ways, the test plan serves as a summary of the test activities that will be performed.
It shows how the tests will be organized, and outlines all of the testers’ needs which must be met in order to properly carry out the test.
The test plan should be inspected by members of the engineering team and senior managers.
Test Cases
A test case is a description of a specific interaction that a tester will have in order to test a single behavior of the software. Test cases are very similar to use cases, in that they are step-by-step narratives which define a specific interaction between the user and the software.
A typical test case is laid out in a table, and includes:
A unique name and number
A requirement which this test case is exercising
Preconditions which describe the state of the software before the test case (which is often a previous test case that must always be run before the current test case)
Steps that describe the specific steps which make up the interaction
Expected Results which describe the expected state of the software after the test case is executed
Test cases must be repeatable.
Good test cases are data-specific, and describe each interaction necessary to repeat the test exactly.
Test Execution
The software testers begin executing the test plan after the programmers deliver the alpha build, or a build that they feel is feature complete.
The alpha should be of high quality—the programmers should feel that it is ready for release, and as good as they can get it.
There are typically several iterations of test execution.
The first iteration focuses on new functionality that has been added since the last round of testing.
A regression test is a test designed to make sure that a change to one area of the software has not caused any other part of the software which had previously passed its tests to stop working.
Regression testing usually involves executing all test cases which have previously been executed.
There are typically at least two regression tests for any software project.
Defect Tracking
The defect tracking system is a program that testers use to record and track defects. It routes each defect between testers, developers, the project manager and others, following a workflow designed to ensure that the defect is verified and repaired.
Every defect encountered in the test run is recorded and entered into a defect tracking system so that it can be prioritized.
The defect workflow should track the interaction between the testers who find the defect and the programmers who fix it. It should ensure that every defect can be properly prioritized and reviewed by all of the stakeholders to determine whether or not it should be repaired. This process of review and prioritization referred to as triage.
Smoke Tests
A smoke test is a subset of the test cases that is typically representative of the overall test plan.
Smoke tests are good for verifying proper deployment or other non invasive changes.
They are also useful for verifying a build is ready to send to test.
Smoke tests are not substitute for actual functional testing.
Test Automation
Test automation is a practice in which testers employ a software tool to reduce or eliminate repetitive tasks.
Testers either write scripts or use record-and-playback to capture user interactions with the software being tested.
This can save the testers a lot of time if many iterations of testing will be required.
It costs a lot to develop and maintain automated test suites, so it is generally not worth developing them for tests that will executed only a few times.
Postmortem Reports
The postmortem report is an overall account of the team’s experience in building the software, and of the experience of the users and stakeholders in working with the team.
The report should contain an honest assessment of how the team members, users, and stakeholders perceived the end product, and assessed the decisions made throughout the project.
The purpose of the post-mortem report is to highlight the team’s successes and identify any problems which should be fixed in future releases.

[attachment=14604]
Software Project ManagementRational Unified Framework
Part 1 Software Management RenaissanceIntroduction
In the past ten years, typical goals in the software process improvement of several companies are to achieve a 2x, 3x, or 10x increase in productivity, quality, time to market, or some combination of all three, where x corresponds to how well the company does now.
The funny thing is that many of these organizations have no idea what x is, in objective terms.
Part 1 Software Management Renaissance
Part 1Software Management RenaissanceTable of Contents (1)
The Old Way (Conventional SPM)
The Waterfall Model
Conventional Software Management Performance
Evolution of Software Economics
Software Economics
Pragmatic Software Cost Estimation
Part 1 Software Management RenaissanceTable of Contents (2)
Improving Software Economics
Reducing Software Product Size
Improving Software Processes
Improving Team Effectiveness
Improving Automation through Software Environments
Achieving Required Quality
Peer Inspections: A Pragmatic View
The Old Way and the New
The Principles of Conventional Software Engineering
The Principles of Modern Software Management
Transitioning to an Iterative Process
The Old Way
Part 1 The Old Way
Software crisis
“The best thing about software is its flexibility”
It can be programmed to do almost anything.
“The worst thing about software is also its flexibility”
The “almost anything ” characteristic has made it difficult to plan, monitor, and control software development.
Part 1 The Old WayThe Waterfall Model
Drawbacks
Protracted integration
and late design breakage
Late risk resolution
Requirements - driven
functional decomposition
Adversarial stakeholder relationships
Focus on document
and review meetings
Part 1 The Old Way Conventional Software Management Performance
Finding and fixing a software problem after delivery costs 100 times more than finding and fixing the problem in early design phases.
You can compress software development schedules 25% of nominal, but no more.
For every $1 you spend on development, you will spend $2 on maintenance.
Software development and maintenance costs are primarily a function of the number of source lines of code.
Variations among people account for the biggest differences in software productivity.
The overall ratio of software to hardware costs is still growing. In 1955 it was 15:85; in 1985, 85:15.
Only about 15% of software development effort is devoted to programming.
Walkthroughs catch 60% of the errors.
80% of the contribution comes from 20% of contributors.
Part 1 Evolution of Software Economics
Part 1 Evolution of Software Economics
Most software cost models can be abstracted into a function of five basic parameters:
Size (typically, number of source instructions)
Process (the ability of the process to avoid non-value-adding activities)
Personnel (their experience with the computer science issues and the applications domain issues of the project)
Environment (tools and techniques available to support efficient software development and to automate process)
Quality (performance, reliability, adaptability…)
Part 1 Evolution of Software EconomicsThree generations of software economics
Part 1 Evolution of Software EconomicsThe predominant cost estimation process
Part 1 Evolution of Software EconomicsPragmatic software cost estimation
A good estimate has the following attributes:
It is conceived and supported by the project manager, architecture team, development team, and test team accountable for performing the work.
It is accepted by all stakeholders as ambitious but realizable.
It is based on a well defined software cost model with a credible basis.
It is based on a database of relevant project experience that includes similar processes, technologies, environments, quality requirements, and people.
It is defined in enough detail so that its key risk areas are understood and the probability of success is objectively assessed.

Part 1  Improving Software Economics 
Five basic parameters of the software cost model:
Reducing the size or complexity of what needs to be developed
Improving the development process
Using more-skilled personnel and better teams (not necessarily the same thing)
Using better environments (tools to automate the process)
Trading off or backing off on quality thresholds
Part 1 Improving Software EconomicsImportant trends in improving software economics
Cost model parameters Trends
Part 1 Improving Software EconomicsReducing Software Product Size
“The most significant way
to improve affordability and return on investment is usually to produce a product that achieves the design goals with the minimum amount of human-generated source material.”
Part 1 Improving Software EconomicsReducing Software Product Size - Languages
Part 1 Improving Software EconomicsReducing Software Product Size – Object-Oriented Methods
“An object-oriented model of the problem and its solution encourages a common vocabulary between the end users of a system and its developers, thus creating a shared understanding of the problem being solved.”
Here is an example of how object-oriented technology permits corresponding improvements in teamwork and interpersonal communications.
“The use of continuous integration creates opportunities to recognize risk early and make incremental corrections without destabilizing the entire development effort.”
This aspect of object-oriented technology enables an architecture-first process, in which integration is an early and continuous life-cycle activity.
An object-oriented architecture provides a clear separation of concerns among disparate elements of a system, creating firewalls that prevent a change in one part of the system from rending the fabric of the entire architecture.”
This feature of object-oriented technology is crucial to the supporting languages and environments available to implement object-oriented architectures.
Part 1 Improving Software EconomicsReducing Software Product Size – Reuse
Number of Projects Using Reusable Components
Part 1 Improving Software EconomicsReducing Software Product Size – Commercial Components
Part 1 Improving Software EconomicsImproving Software Processes

Part 1 Improving Software EconomicsImproving Team Effectiveness (1)
The principle of top talent: Use better and fewer people.
The principle of job matching: Fit the task to the skills an motivation of the people available.
The principle of career progression: An organization does best in the long run by helping its people to self-actualize.
The principle of team balance: Select people who will complement and harmonize with one another.
The principle of phase-out: Keeping a misfit on the team doesn’t benefit anyone.
Part 1 Improving Software EconomicsImproving Team Effectiveness (2)
Important Project Manager Skills:
Hiring skills. Few decisions are as important as hiring decisions. Placing the right person in the right job seems obvious but is surprisingly hard to achieve.
Customer-interface skill. Avoiding adversarial relationships among stake-holders is a prerequisite for success.
Decision-making skill. The jillion books written about management have failed to provide a clear definition of this attribute. We all know a good leader when we run into one, and decision-making skill seems obvious despite its intangible definition.
Team-building skill. Teamwork requires that a manager establish trust, motivate progress, exploit eccentric prima donnas, transition average people into top performers, eliminate misfits, and consolidate diverse opinions into a team direction.
Selling skill. Successful project managers must sell all stakeholders (including themselves) on decisions and priorities, sell candidates on job positions, sell changes to the status quo in the face of resistance, and sell achievements against objectives. In practice, selling requires continuous negotiation, compromise, and empathy.
Part 1 Improving Software EconomicsAchieving Required Quality
Key practices that improve overall software quality:
Focusing on driving requirements and critical use cases early in the life cycle, focusing on requirements completeness and traceability late in the life cycle, and focusing throughout the life cycle on a balance between requirements evolution, design evolution, and plan evolution
Using metrics and indicators to measure the progress and quality of an architecture as it evolves from a high-level prototype into a fully compliant product
Providing integrated life-cycle environments that support early and continuous configuration control, change management, rigorous design methods, document automation, and regression test automation
Using visual modeling and higher level language that support architectural control, abstraction, reliable programming, reuse, and self-documentation
Early and continuous insight into performance issues through demonstration-based evaluations
Part 1 The Old Way and the New
Part 1 The Old Way and the NewThe Principles of Conventional Software Engineering
Make quality #1. Quality must be quantified and mechanism put into place to motivate its achievement.
High-quality software is possible. Techniques that have been demonstrated to increase quality include involving the customer, prototyping, simplifying design, conducting inspections, and hiring the best people.
Give products to customers early. No matter how hard you try to learn users’ needs during the requirements phase, the most effective way to determine real needs is to give users a product and let them play with it.
Determine the problem before writing the requirements. When faced with what they believe is a problem, most engineers rush to offer a solution. Before you try to solve a problem, be sure to explore all the alternatives and don’t be blinded by the obvious solution.
Evaluate design alternatives. After the requirements are agreed upon, you must examine a variety of architectures and algorithms. You certainly do not want to use an “architecture” simply because it was used in the requirements specification.
Use an appropriate process model. Each project must select a process that makes the most sense for that project on the basis of corporate culture, willingness to take risks, application area, volatility of requirements, and the extent to which requirements are well understood.
Use different languages for different phases. Our industry’s eternal thirst for simple solutions to complex problems has driven many to declare that the best development method is one that uses the same notation through-out the life cycle. Why should software engineers use Ada for requirements, design, and code unless Ada were optimal for all these phases?
Minimize intellectual distance. To minimize intellectual distance, the software’s structure should be as close as possible to the real-world structure.
Put techniques before tools. An undisciplined software engineer with a tool becomes a dangerous, undisciplined software engineer.
Get it right before you make it faster. It is far easier to make a working program run than it is to make a fast program work. Don’t worry about optimization during initial coding.
Part 1 The Old Way and the NewThe Principles of Conventional Software Engineering
Inspect code. Inspecting the detailed design and code is a much better way to find errors than testing.
Good management is more important than good technology. The best technology will not compensate for poor management, and a good manager can produce great results even with meager resources. Good management motivates people to do their best, but there are no universal “right” styles of management.
People are the key to success. Highly skilled people with appropriate experience, talent, and training are key. The right people with insufficient tools, languages, and process will succeed. The wrong people with appropriate tools, languages, and process will probably fail.
Follow with care. Just because everybody is doing something does not make it right for you. It may be right, but you must carefully assess its applicability to your environment. Object orientation, measurement, reuse, process improvement, CASE, prototyping-all these might increase quality, decrease cost, and increase user satisfaction. The potential of such techniques is often oversold, and benefits are by no means guaranteed or universal.
Take responsibility. When a bridge collapses we ask, “what did the engineers do wrong?” Even when software fails, we rarely ask this. The fact is that in any engineering discipline, the best methods can be used to produce awful designs, and the most antiquated methods to produce elegant design.
Understand the customer’s priorities. It is possible the customer would tolerate 90% of the functionality delivered late if they could have 10% of it on time.
The more they see, the more they need. The more functionality (or performance) you provide a user, the more functionality (or performance) the user wants.
Plan to throw one away .One of the most important critical success factors is whether or not a product is entirely new. Such brand-new applications, architectures, interfaces, or algorithms rarely work the first time.
Design for change. The architectures, components, and specification techniques you use must accommodate change.
Design without documentation is not design. I have often heard software engineers say, “I have finished the design. All that is left is the documentation.”
Part 1 The Old Way and the NewThe Principles of Conventional Software Engineering
21.Use tools, but be realistic. Software tools make
Part 1 The Old Way and the NewThe Principles of Modern Software Management
The central design element
Part 2 A Software Management Process Framework
Part 2 A Software Management Process FrameworkTable of Contents (1)
Life-Cycle Phases
Engineering and Production Stages
Inception Phase
Elaboration Phase
Construction Phase
Transition Phase
Artifacts of the Process
The Artifact Sets
Management Artifacts
Engineering Artifacts
Pragmatic Artifacts
Part 2 A Software Management Process FrameworkTable of Contents (2)
Model-based software Architectures
Architecture: A Management Perspective
Architecture: A Technical Perspective
Workflows of the Process
Software Process Workflows
Iteration Workflows
Checkpoints of the Process
Major Milestones
Minor Milestones
Periodic Status Assessments
Part 2 Life-Cycle PhasesEngineering and Production Stages
Part 2 Life-Cycle PhasesEngineering and Production Stages
Part 2 Life-Cycle PhasesInception Phase
Part 2 Life-Cycle PhasesElaboration Phase
Part 2 Life-Cycle PhasesConstruction Phase
Part 2 Life-Cycle PhasesTransition Phase
Part 2 Life-Cycle Phases
Part 2 Artifacts of the Process
Part 2 Artifacts of the ProcessManagement Artifacts
Part 2 Artifacts of the ProcessManagement Artifacts
Part 2 Artifacts of the ProcessManagement Artifacts
Part 2 Artifacts of the ProcessEngineering Artifacts
Part 2 Artifacts of the ProcessEngineering Artifacts
Part 2 Artifacts of the ProcessPragmatic Artifacts
Part 2  Model-Based Software Architectures A Management Perspective
Part 2  Model-Based Software Architectures A Management Perspective
Part 2  Model-Based Software Architectures A Technical Perspective
Part 2  Model-Based Software Architectures A Technical Perspective
Part 2  Workflows of the Process Software Process Workflows
Part 2  Workflows of the Process Software Process Workflows
Part 2  Workflows of the Process Iteration Workflows
Part 2  Workflows of the Process Iteration Workflows
Part 2  Checkpoints of the Process
Part 2  Checkpoints of the Process
Part 3Software Management Disciplines






Part 3Software Management DisciplinesTable of Contents (1)
Iterative Process Planning
Work Breakdown Structures
Planning Guidelines
The Cost and Schedule Estimating Process
The Iteration Planning Process
Pragmatic Planning
Project Organizations and Responsibilities
Line-of-Business organizations
Project Organizations
Evolution Organizations
Process Automation
Tools: Automation Building Blocks
The Project Environment
Part 3 Software Management DisciplinesTable of Contents (2)
Project Control and Process Instrumentation
The Seven Core Metrics
Management Indicators
Quality Indicators
Life-Cycle Expectations
Pragmatic Software Metrics
Metrics Automation
Tailoring the Process
Process Discriminants
Example: Small-Scale Project Versus Large-scale Project
Part 3Iterative Process PlanningWork Breakdown Structures
Part 3Iterative Process PlanningPlanning Guidelines
Part 3Iterative Process PlanningThe Cost and Schedule Estimating Process
Part 3Iterative Process PlanningThe Cost and Schedule Estimating Process
Part 3Iterative Process PlanningThe Iteration Planning Process
Part 3Project Organizations and ResponsibilitiesLine-of-Business Organizations
Default roles in a software line-of-business organizations
Part 3Project Organizations and ResponsibilitiesProject Organizations
Software Management Team
Part 3Project Organizations and ResponsibilitiesProject Organizations
Software Architecture Team
Part 3Project Organizations and ResponsibilitiesProject Organizations
Software Development Team
Part 3Project Organizations and ResponsibilitiesProject Organizations
Software Assessment Team
Part 3Project Organizations and ResponsibilitiesEvolution of Organizations
Part 3Process Automation Computer-aided software engineering
Computer-aided software engineering (CASE) is software to support software development and evolution processes.
Activity automation
Graphical editors for system model development;
Data dictionary to manage design entities;
Graphical UI builder for user interface construction;
Debuggers to support program fault finding;
Automated translators to generate new versions of a program.
Part 3Process Automation Computer-aided software engineering (CASE) Technology
Case technology has led to significant improvements in the software process. However, these are not the order of magnitude improvements that were once predicted
Software engineering requires creative thought - this is not readily automated;
Software engineering is a team activity and, for large projects, much time is spent in team interactions. CASE technology does not really support these.
Part 3Process Automation CASE Classification
Classification helps us understand the different types of CASE tools and their support for process activities.
Functional perspective
Tools are classified according to their specific function.
Process perspective
Tools are classified according to process activities that are supported.
Integration perspective
Tools are classified according to their organisation into integrated units.
Part 3Process Automation Functional Tool Classification
Part 3Process Automation CASE Integration
Tools
Support individual process tasks such as design consistency checking, text editing, etc.
Workbenches
Support a process phase such as specification or design, Normally include a number of integrated tools.
Environments
Support all or a substantial part of an entire software process. Normally include several integrated workbenches.
Part 3Process Automation Tools, Workbenches, Environments
Part 3Project Control and Process Instrumentation The Core Metrics
Part 3Tailoring the ProcessProcess Discriminants
The two primary dimensions of process variability
Part 3Tailoring the ProcessExample: Small-Scale Project vs. Large-Scale Project
Differences in workflow priorities between small and large projects
Part 4 Looking Forward
Part 4 Looking ForwardTable of Contents
Modern Project Profiles
Continuous Integration
Early Risk Resolution
Evolutionary Requirements
Teamwork Among Stakeholders
Top 10 Software Management Principles
Software Management Best Practices
Next-Generation Software Economics
Next-Generation Cost Models
Modern Software Economics
Modern Process Transitions
Culture Shifts
Denouement
Part 4 Modern Project ProfilesContinuous Integration
Part 4 Modern Project ProfilesContinuous Integration
Part 4 Modern Project ProfilesEarly Risk Resolution
Part 4 Modern Project ProfilesEvolutionary Requirements
Part 4 Modern Project ProfilesTeamwork among stakeholders
Part 4 Modern Project ProfilesTop 10 Software Management Principles
Part 4 Modern Project ProfilesTop 10 Software Management Principles
Part 4 Modern Project ProfilesSoftware Management Best Practices
Part 4 Next-Generation Software EconomicsNext-Generation Cost Models
Part 4 Next-Generation Software EconomicsNext-Generation Cost Models
Part 4 Next-Generation Software EconomicsModern Software Economics
Part 4 Next-Generation Software EconomicsModern Software Economics
Part 4 Modern Process TransitionsCulture Shifts
Part 4 Modern Process TransitionsDenouement
Appendix
AppendixUse Case Analysis
What is a Use Case?
A sequence of actions a system performs that yields a valuable result for a particular actor.
What is an Actor?
A user or outside system that interacts with the system being designed in order to obtain some value from that interaction
Use Cases describe scenarios that describe the interaction between users of the system and the system itself.
Use Cases describe WHAT the system will do, but never HOW it will be done.
Appendix What’s in a Use Case?
Define the start state and any preconditions that accompany it
Define when the Use Case starts
Define the order of activity in the Main Flow of Events
Define any Alternative Flows of Events
Define any Exceptional Flows of Events
Define any Post Conditions and the end state
Mention any design issues as an appendix
Accompanying diagrams: State, Activity, Sequence Diagrams
View of Participating Objects (relevant Analysis Model Classes)
Logical View: A View of the Actors involved with this Use Case, and any Use Cases used or extended by this Use Case
Appendix Use Cases Describe Function not Form
Use Cases describe WHAT the system will do, but never HOW it will be done.
Use Cases are Analysis Products, not Design Products.
Appendix Use Cases Describe Function not Form
Use Cases describe WHAT the system should do, but never HOW it will be done
Use cases are Analysis products, not design products
Appendix Benefits of Use Cases
Use cases are the primary vehicle for requirements capture in RUP
Use cases are described using the language of the customer (language of the domain which is defined in the glossary)
Use cases provide a contractual delivery process (RUP is Use Case Driven)
Use cases provide an easily-understood communication mechanism
When requirements are traced, they make it difficult for requirements to fall through the cracks
Use cases provide a concise summary of what the system should do at an abstract (low modification cost) level.
Appendix Difficulties with Use Cases
As functional decompositions, it is often difficult to make the transition from functional description to object description to class design
Reuse at the class level can be hindered by each developer “taking a Use Case and running with it”. Since UCs do not talk about classes, developers often wind up in a vacuum during object analysis, and can often wind up doing things their own way, making reuse difficult
Use Cases make stating non-functional requirements difficult (where do you say that X must execute at Y/sec?)
Testing functionality is straightforward, but unit testing the particular implementations and non-functional requirements is not obvious
Appendix Use Case Model Survey
The Use Case Model Survey is to illustrate, in graphical form, the universe of Use Cases that the system is contracted to deliver.
Each Use Case in the system appears in the Survey with a short description of its main function.
Participants:
Domain Expert
Architect
Analyst/Designer (Use Case author)
Testing Engineer

Appendix Sample Use Case Model Survey
Appendix Analysis Model
In Analysis, we analyze and refine the requirements described in the Use Cases in order to achieve a more precise view of the requirements, without being overwhelmed with the details
Again, the Analysis Model is still focusing on WHAT we’re going to do, not HOW we’re going to do it (Design Model). But what we’re going to do is drawn from the point of view of the developer, not from the point of view of the customer
Whereas Use Cases are described in the language of the customer, the Analysis Model is described in the language of the developer:
Boundary Classes
Entity Classes
Control Classes
Appendix Why spend time on the Analysis Model, why not just “face the cliff”?
By performing analysis, designers can inexpensively come to a better understanding of the requirements of the system
By providing such an abstract overview, newcomers can understand the overall architecture of the system efficiently, from a ‘bird’s eye view’, without having to get bogged down with implementation details.
The Analysis Model is a simple abstraction of what the system is going to do from the point of view of the developers. By “speaking the developer’s language”, comprehension is improved and by abstracting, simplicity is achieved
Nevertheless, the cost of maintaining the AM through construction is weighed against the value of having it all along.
Appendix Boundary Classes
Boundary classes are used in the Analysis Model to model interactions between the system and its actors (users or external systems)
Boundary classes are often implemented in some GUI format (dialogs, widgets, beans, etc.)
Boundary classes can often be abstractions of external APIs (in the case of an external system actor)
Every boundary class must be associated with at least one actor:
Appendix Entity Classes
Entity classes are used within the Analysis Model to model persistent information
Often, entity classes are created from objects within the business object model or domain model
Appendix Control Classes
The Great Et Cetera
Control classes model abstractions that coordinate, sequence, transact, and otherwise control other objects
In Smalltalk MVC mechanism, these are controllers
Control classes are often encapsulated interactions between other objects, as they handle and coordinate actions and control flows.
Literature
Software Project Management
A Unified Framework
Walker Royce
Software Processes
©Ian Sommerville 2004
Process and Method:
An Introduction to the Rational Unified Process