Software Engineering Process & Management

SOFTWARE PROCESS

The Ultimate GOAL of Software Development: To deliver QUALITY products ON TIME and ON BUDGET which meet the customer’s REAL NEED.

A software process: a set of activities and associated results which produce a software product.
Process defines Who is doing What, When and How to reach certain goal (to build a software product or to enhance an existing one).
Set of activities, implies methods, procedures and tools, includes: Software Specification, Software Development, Software Validation, Software Evolution (Maintenance)
Software Process Model: A simplified description of a software process which is presented from a particular perspective. Ie. Data Flow Diagram represents the process as a set of activities each of which carries out some data transformation.
Includes: Waterfall, Spiral, Evolutionary Prototyping.
A software engineering method: a structured approach to software development to facilitate the production of high-quality software in a cost effective way.
Attributes of Good Software:
Maintainability mudah diperbaiki dan dikembangkan
Dependability reliable, secure and safe, tidak terganggu oleh system failure
Eficiency dalam penggunaan resource seperti memori dan processor
Usability approriate interface and adequate documentation

Software Engineering Key Challenges
Legacy the challenge of maintaining and updating the software (minimal cost, continual business service).
Hetergeneity the challenge of developing techniques to build dependable software across network that include different computers and support system.
Delivery the challenge to provide appropriate user interface and adequate user manual.

Sofware Engineering Methodologies
Monumental / Heavy Weight, including code build and fix, Software Life Cycle Model, Personal working style improvement.
Light Weight, including Agile Process Model (XP, Scrum), Kompetensi, Sikap, Etos kerja personel
Framework, Capability maturity model (CMMI-SW, CMMI-DEV)
Best Practise, publikasi pengalaman.

Software Crisis
Ditandai dengan gagalnya produk perangkat lunak: kualitas buruk, over budget, overtime.
Disebabkan oleh pengelolaan yang tidak baik: rumusan spesifikasi yang buruk, tidak konsisten antara rancangan dan implementasi, tidak ada mekanisme kontrol kualitas
Mitos dan Realita
Manajemen Alat Bantu
Mitos: sudah disediakan buku panduan tentang bakuan dan prosedur untuk membangun perangkat lunak, alat bantu yang canggih, komputer generasi terbaru, semestinya staf sudah dapat bekerja dengan dengan baik.
Realita: Apakah pengembang mempedulikan keberadaannya? Sudah lengkapkah? Apakah alat bantu itu memang sesuai dengan yang dibutuhkan? Apakah kompetensi pengembang yang menjadi masalah?
Manajemen Waktu dan Tenaga
Mitos: Jika terlambat dalam menyelesaikan pengembangan, kita dapat menambah orang lebih banyak dan menyelesaikan keterlambatan.
Realita: Membuat perangkat lunak bukan proses mekanis seperti manufaktur. Penambahan orang justru akan memperburuk proses yang terlambat.
Klien
Mitos: Sebuah kalimat umum yang menyatakan kebutuhan yang diinginkan sudah cukup tanpa harus diperinci.
Realitas: Perlu deskripsi yang rinci mengenai ruang lingkup informasi, fungsi-fungsi, sistem interaksi, batasan-batasan dan kriteria validasi. Rancangan yang lengkap lebih baik dari rancangan yang tambal sulam.
Pengembang
Mitos: Makin cepat melakukan coding, makin cepat pengembangannya dan makin cepat selesai perkerjaan kita.
Realita: Perlu cukup waktu untuk menyiapkan rancangan, uji kualitas sudah dapat dilakukan melalui uji kualitas kebutuhan terhadap rancangan dan rancangan terhadap coding, tidak harus menunggu program jadi.
Mitos: Produk yang perlu diberikan oleh proyek yang sukses adalah programnya saja.
Realitas: Program hanyalah salah satu komponen dari perangkat lunak. Dokumentasi penting sebagai acuan tidak hanya untuk mpengembangan yang sukses tetapi juga sebagai petunjuk pemakaian dan pemeliharaan perangkat lunak.

Peran dalam Pengembangan Perangkat Lunak
Project Manager, System Analyst, Programmer, Software tester, Software inspector, Software librarian, Change controller, Technical writer, Database administrator, Network administrator, User.

Cakupan Rekayasan Perangkat Lunak
Methodologies, sekumpulan metoda untuk melaksanakan setiap tahap pengembangan.
Tools, CASE tools
Procedures, manajemen kegiatan

CMM (Capability Maturity Model)

Underlying the CMM
The belief that the use of new software techniques will not in itself result in increased productivity and profitability, because the cause of our problem is how we manage the software process.
CMM assists an organizations in providing the infrastructure for a disciplined and mature software process.

5 Level of Software Process Maturity
1. INITIAL Unpredictable and Poorly Controlled [Project Manaagement] >> disciplined process
2. REPEATABLE can repeat previously mastered tasks –[Integrated Engineering Process] >> standard, consistent process
3. DEFINED Process Characterized, fairly well understood [Product and Process Quality] >> predictable process
4. MANAGED Process measured and controlled [Managing Change] >> continuously improving process
5. OPTIMIZING Focus on process improvement
How to use CMM
- Hire an officially certified CMM Assessor to conduct a formal valuation.
- Send your own people to official CMM training, then conduct internal assessments.
- Use CMM as a set of suggestions and apply as you see fit.
KEY PROCESS AREAS
Level 2: Requirement Management, Softwa Project Panning, Software Project Tracking and Oversight, Software Subcontract Management, Software Quality Assurance, Software Configuration Management.
Level 3: Organization Process Definition, Training Program, Integrated Software Management, Inter-Group Coordination, Peer Reviews.
Level 4: Process Measurement and Analysist, Software Quality Management (SQM).
Level 5: Defect Prevention, Technology Innovation, Process Change Management.
Quantifiable Benefits
- Cost of development goes down
- Better level of control on project changes
- Project metrics at enterprise level controls impact of change
- Process consistency across all agencies allows benchmarking and best practices to be shared at the enterprise level
- Reduced time to market has a positive impact on business and IT
- Better resource allocation
- Mitigates single point of failure
- Increases percentage of projects on-time and on-budget
- Better project forecast based on historical project data
- SDLC will lend itself to level 3
- A better product
CMMI-DEV
3 Dimensions on organization
People, Procedures and Methods, Tools and Equipment
Capability Levels reflect the process improvement achievement in particular process area.
Capability Levels
Level 0: Incomplete
Level 1: Performed, Process unpredictable, poorly controlled, and reactive.
Level 2: Managed, Process characterized for projects and is often reactive.
Level 3: Defined, Process characterized for organization and is proactive..
Level 4: Quantitatively Managed, Process measured and controlled.
Level 5: Optimizing, Focus on continuous process improvement.
Continuous vs Staged
CONTINUOUS
- 5 Generic Goals
- Basic and Advanced Specific Practices for Engineering Pas
- Progress can be made PA by PA basis
- Rating via achievement profile ie. Ratings on different PAs
- Allows flexible approach addressing business need
- Defines Capability Level 1 useful for SME
- Equivalent staging permits comparison to Staged
STAGED
- 2 Generic Goals
- Only one set of Specific practices per Process Area
- Progress is made on groups of PAs related to a maturity level
- Organizational maturity level rating
- Progress is made on well defined path
- Allows somewhat easier transition from CMM.
- Maturity ratings are easy for customers like Hotel star rating
Mapping: ML2 = CL2, ML3 / ML4 / ML 5 = CL3
4 (of 7) PROCESS AREA OF MATURITY LEVEL 2
REQM (REQUIREMENTS MANAGEMENT)
Requirements Basic Reasons
- Form the basis for agreement
- Define the scope and character of project work
- Serve as objective success criteria
- Naturally subject to change
- Establish a legal responsibility
SG 1Manage Requirements
SP 1.1 Obtain an undestanding of the requirements
SP 1.2 Obtain commitment to the requirements
SP 1.3 Manage requirements changes
SP 1.4 Maintain bi-directional traceability of requirements
SP 1.5 Identify inconsistencies between project work and requirements
BENEFIT OF RM
- Synchronicity
- Enhanced Control
- Management Visibility
- A standard for fulfillment
CM (CONFIGURATION MANAGEMENT)
CM: controlling the configuration and integrity of work products
Work Products: any cohesive and persistent information that is produced as a consequence of one or more software engineering action of tasks (plan (schedule, budget, resources), working software, documentation, design, etc)
Reason: work products are produced & maintaned in dynamic environment, subject to change
Purpose: establish official product baselines and then coordinate, evaluate, approve, and manage changes to those baselines.
Elements: Development plans, Functional requirements, Software codes, Network/Hardware configurations, User manual, etc
Typical aspects to be implemented:
- a repository for artifacts and baselines
- a structured approach for work coordination
- a platform for change management
- a control point for data integrity
SG 1 Establish Baseline
SP 1.1 Identify configuration items
SP 1.2 Establish a configuration management system
SP 1.3 Create or release baseline
SG 2 Track and Control Changes
SP 2.1 Track change requests
SP 2.2 Control configuration items
SG 3 Establish Integrity
SP 3.1 Establish Configuration Management Records
SP 3.2 Perform Configurations Audits
BENEFITS OF CM
- Referencial Integrity
- Change Control
- Statutory complience
- Workflow control
PP (PROJECT PLANNING)
Plan is: “… a formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions , facilitate communication among stakeholders, and document approved scope, cost, and schedule baselines. A Project plan may be summarized or detailed.” (PMBOK)
Plan Consist of: Project Schedule (Gantt Chart), Project Charter (narrative)
Purpose Establish and maintain documented plans that define project activities (management plans): Project scope, Schedule, Cost, Quality, Process Improvement, Staffing, Communication, Risk, Procurement, etc.
Characteristic Main output is Project Plan, the bases for performing and controlling the project’s activities that address the commitments with the customer.
SG 1 Establish Estimates
SP 1.1 Estimate the scope of the project
SP 1.2 Establish estimates of work product and task attributes
SP 1.3 Define project lifecycle
SP 1.4 Determine estimates of effort and cost
SG 2 Develop a Project Plan
SP 2.1 Establish the budget and schedule
SP 2.2 Identify project risks
SP 2.3 Plan for data management
SP 2.4 Plan for project resources
SP 2.5 Plan for needed knowledge and skiils
SP 2.6 Plan stakeholder involvement
SP 2.7 Establish a project plan
SG 3 Obtain Commitment to the Plan
SP 3.1 Review plans that affect the Project
SP 3.2 Reconcile work and resource levels
SP 3.3 Obtain plan commitment
BENEFITS
- A systematic plan for realistic planning
- A definition of success
- A contract of agreement and action
- A common basis for decision making
PMC (PROJECT MONITORING AND CONTROL)
Purpose
- Guide of Work
- Protect Commitment
- Promote Communication
- Facilitate Correction, adjustment and focus
SG 1 Monitor Project Against Plan
SP 1.1 Monitor project planning parameters
SP 1.2 Monitor commitments
SP 1.3 Monitor project risks
SP 1.4 Monitor data management
SP 1.5 Monitor stakeholder involvement
SP 1.6 Conduct progress reviews
SP 1.7 Conduct milestone reviews
SG 2 Manage Corrective Action to Closure
SP 2.1 Analyze Issues
SP 2.2 Take corrective action
SP 2.3 Manage corrective action
BENEFITS
- A Platform for value management
- A Common Language of progress and oversight
- A project management performance bar
- Consistency in PMO Operations

AGILE DEVELOPMENT

Manifesto
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Agile as Philosophy, Set of Development Guidelines
Agile Team Member Traits
Competence, Common focus, Collaboration, Decision making ability, Fuzzy problem solving ability, Mutual trust and respect, Team self-organization
Steps of Agile Development
Customer Communication, Planning, Modeling, Construction, Delivery, Evaluation
The only important work product is an operational “software increment” that is delivered to the customer on the appropriate commitment date.
The assurance, if the agile team agrees that the process works and the team produces deliverable software increments that satisfy the customer, then it is done right.
When not to use it
- the software is being developed by teams who are not co-located
- should also be avoided for critical system, except for test first development from agile approach
Extreme Programming
VALUES: Communication, simplicity, Feedback, Courage, Respect
PROCESS: Planning, Design, Coding, Testing, Release
PLANNING: Create User Stories, assign a value (ie. Priority) to each story, assess stories and assign a cost, Stories grouped for a delivery increment, Project velocities is used to help define subsequent delivery date for other increments.
KIS (Keep it Simple) , CRC (Class-Responsibility-Collaborator) card.
Spike Solution, if a difficult design problem is encountered when design a story, create an operational prototype of that portion of design. It will help lower risk when true implementation start and validate original estimates.
REFACTORING: an iterative refinement of the internal program design.
Construction of unit test before the coding commences
PAIR PROGRAMMING, Two people work together at one workstation to create code for a story. PP leads to continuous informal reviewing, information sharing is implicit, encourages refactoring, people are likely to spend less time in fine-grain optimization.
Continuous integration and smoke testing: a common approach for creating daily builds for product software
TESTING: Unit tests, Smoke Test, Integration and Validation test, Acceptence test
CORE PRACTISES: Planning, Small Release, Simple Design, Continuous Testing, Refactoring, Pair Programming, Collective Code Ownership, Continuous Integration, 40H working week, On Site Customer, Coding Standards
SCRUM
PRINCIPLES Small Working Team, Process must be adaptable, Frequent Increments, Low coupling partitions, declare the product done.
PROCESS Product Backlog, Sprint Backlog, Daily Scrum Meeting, Potentially Shippable Product Increment
ROLES Pig Roles (Scrum Master, Product Owner, Team) Chicken Role (Stakeholders, Managers)
MEETING: Daily Scrum, Planning Meeting, Review Meeting
ARTIFACTS: Product-backlog, Sprint-backlog, Burn Down